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?
vague.
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...) </F>