"M.-A. Lemburg" wrote:
Jim Fulton wrote:
major issues right now is 1. should the type know about timezones (probably not),
:(
-1
Doesn't the proposal sort of imply time-zone awareness of some kind? Or does it simply imply UT storage?
I tried that in early version of mxDateTime -- it fails badly. I switched to the local time assumption very early in the development.
That's a really bad assumption if times are used in different time zones.
Note that Fredrik's type is an abstract type; it doesn't even store anything -- that's up to subtypes which of course can implement timezones at their liking.
No, it does store something, it just doesn't say how. There are methods for returning localtime and gmtime, so there is (abstract) storage.
and 2. should it support basic arithmetics (probably yes).
Does this imply leap second hell, or will we simply be vague about expectations?
The type will store a fixed point in time, so why worry about leap seconds (most system's don't support these anyway and if they do, the support is usually switched off per default) ?
There are a lot of semantic issues with date-time math. Leap seconds is an example. If you store local time, are date-time subtractions affected by daylight-savings time? Do the calculations depend on the calendar? Do you take into account the lost days in the switch from the Julean to the Gregorian calendar? I'm not really opposed to doing math, but we need to at least recognize the fuzzyness of the semantics.
I'd also like to see simple access methods for year, month, day, hours, minutes, and seconds, with date parts being one based and time parts being zero based.
In the abstract base type ?
Yes. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (888) 344-4332 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org