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

[Guido van Rossum]

[me]
> > Improving upon struct tm is hard (it has all the necessary fields and no
> > others), unless you want to add operations (just add methods) or make
> > the representation more compact (several of the fields can be packed in
> > 4-6 bits each).

[Tim]
> I'm suprised you say "all the necessary fields", because a tm contains no
> info about timezone.

Oops.  My mistake.  I thought it had timezone.

[tmx details snipped]

> > A third dimension might be to provide better date/time arithmetic, but
> > I'm not sure if there's much of a market for that, given all the fuzzy
> > semantics (leap seconds, differences across DST changes, timezones).
> 
> I don't think we can get off that easy.  Time computation is critical for
> businesses and astronomers, and leap seconds etc are a PITA independent of
> time computations.  Time computations seem to me to be the easiest of all,
> provided we've already "done something" intelligible about the rest:  any
> calculation boils down to factoring away leap seconds etc in conversion to a
> canonical form, doing the computing there, then injecting leap seconds etc
> back in to the result when converting out of canonical form again.
> 
> The ECMAScript std (nee Javascript) has, I think, a good example of a usable
> facility that refused to get mired down in impossible details; e.g., it
> flat-out refuses to recognize leap seconds.  mxDateTime is similarly sane,
> but MAL keeps threatening to flirt with insanity <wink>.
> 
> BTW, I doubt there'd be any discussion of leap seconds in the C std if some
> astronomers hadn't been early Unix users.  It's never a net win in the end
> to try to make a scientist happy <0.9 wink>.

I'd be happy to support time computations, provided we keep the leap
seconds out.

I propose a representation that resembles a compressed struct tm (or
tmx), with appropriately-sized bit fields for year, month, day, hour,
minute, second, millisecond, and microsecond, and timezone and DST
info.  Since the most likely situation is extraction in local time,
these should be stored as local time with an explicit timezone.  (I
don't want to store these things in a database without an explicit
timezone, even if it costs another 12 bit field.)  An app extracting
the local time without checking the timezone could be fooled by a time
stored with a different timezone.  Do we care?

Time computations are only slightly complex because they have to be
calendar-aware, but at least they don't have to be DST-aware -- they
can just thake the timezone offset in minutes and apply it.

The DST info should probably be two bits: one telling whether DST is
in effect at the given time, one telling whether DST is honored in the
given timezone.  Maybe it should also allow "missing info" for either.
Details, details.

--Guido van Rossum (home page: http://www.python.org/~guido/)