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. 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.
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) ?
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 ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/