[Python-Dev] proposal: add basic time type to the standard library

Fredrik Lundh fredrik@pythonware.com
Tue, 26 Feb 2002 21:42:02 +0100

jim wrote:

> Doesn't the proposal sort of imply time-zone
> awareness of some kind? Or does it simply imply
> UT storage?

as written, it still implies time-zone awareness.  the question is
whether to remove that constraint (and the utc* methods).

*all* early reviewers argued that time zones are a representation
thingie, and doesn't belong in the abstract type.

I'm tempted to agree, but I'm not sure I can explain why...

> > and 2. should it support basic
> > arithmetics (probably yes).
> Does this imply leap second hell, or will we 
> simply be vague about expectations?


> 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.

use timetuple().

(I rather not add too much stuff to the abstract interface;
the goal is to let MAL turn mxDateTime into a basetime sub-
type without breaking any application code...)