[DB-SIG] Standardized Date-Time class

[Mike Meyer]

> From: Jeffrey Jacobs <timelord@user2.mnsinc.com>
> be the case), there is a strong difference between 61,292,782,211,360
> milliseconds and Wednesday, 10 December 1997 4:50:11.360 UTC,

Yeah - they are radically different presenatations of what I presume
is the same object. One presentation makes the implicit reference
point explicit.

> or even 11 O'Clock and 11 Hours

or 6 bells for that matter. I'd say '11 hundred hours" for the latter,
but that's really confusing.

>  What does it mean to add 1 January to 7 September?

Since neither has any meaning as stated, nothing.

> Although as a general rule, times very close to 0 will probably be
> TimeSpans, if I have that value stored and then forget what my variable
> actually represents, my program could end up telling me it's Monday 1
> January 1 AD 00:01:45.000 UTC.

This is a standard problem

> Although a good programmer will not make
> that mistake, it's nice knowing that the structure of the language won't
> let you make the mistake anyway.  Thus, I really do feel a strong
> proponent of the separation of time and span.

I don't know any programmers that good. However, it's not the
structure of the language, it's the structure of the objects.

Since we're not implementing them, it isn't really up to us. Code
speaks louder than logic.

>         I have thought about this, and think that the only complete
> solution to this problem is to create an Historical Calendar, which does
> not include the 10 days from 5 to 15 October in 15?? when Pope Gregory
> changed the calendar from the Julian model, and would use the Julian model
> for dates before then.

That's not complete. The box I'm sitting at recognizes the change as
per the US (because I lifted the code from Unix), which was 11 days in
September of 1752. The change was recognzied (and recorded) by various
civil authorities as late as this century.

>         Another problem with the idea of a Historical Calendar module is
> that around 8 BC, due to problems with the Roman Government not keeping
> proper track of the leap years, Caesar Augusta decreed that the years 8 BC
> to 8 AD should not be leap years.  Thus, Calculating 29 February 4 AD,
> although valid in the Julian and Gregorian calendar modules, would be
> historically non-existent.  And certainly the Romans were measuring their
> years in years since the founding of Rome, not in years before the
> approximate birth of Christ.  (How would they know?)

Sigh. And what about the standard tale of July & August getting extra
days for political reasons?

> > That's not the only time that they were changed in the US. And the US
> > isn't the only place they've changed.
>         Agreed.  This is a can of worms, and I wouldn't suggest
> supporting retro-fitted DST for every single region of the world.

That's why I suggested using the existing, available code, which
covers a large chunk of that.


>         Yes.  The first implementation I examined was a commercial
> implementation from a certain omnipresent software entity that will
> hopefully get it's but kicked by the US Federal Government, but that's
> another story.  I have been able to examine the GNU implementation of
> tzset(), and realize that the full interpretation of the TZ environment
> variable is more complicated than is implemented in the first version I
> studied.  Basically, TZ has the following form:
> 
> sss[+/-][hh[:mm[:ss]]][lll[+/-][hh[:mm[:ss]]][{d,Jd,Mm.w.d}[/hh[:mm[:ss]]]][,[{d,Jd,Mm.w.d}[/hh[:mm[:ss]]]]]]
> 
> {Phew!}

That's the GNU code. The code I'm referring to has a much simpler use
for TZ, and is much more flexible that this. You can use it to get the
retrofit DST for the past, and change that without changing a line of
your code - because it's all table driven.

I suspect there are a lot more than 51 timezones, but it's hard to
tell. From the looks of things, there are 101 different DST rules in
the Americas, but I'm trying to compare binary data files at this
point.

	<mike



_______________
DB-SIG  - SIG on Tabular Databases in Python

send messages to: db-sig@python.org
administrivia to: db-sig-request@python.org
_______________