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

[Tim Peters]

[Guido]
> ...
> This stuff is hairier than it seems!

You're just getting your toes wet:  it's impossible to make any two of
{astronomers, businessfolk, Jim} happy at the same time, even if they're all
American and live in the same city.

> I think the main tension is between improving upon the Unix time_t type,
> and improving upon the Unix "struct tm" type.  Improving upon time_t
> could mean to extend the range beyond 1970-2038, and/or extend the
> precision to milliseconds or microseconds.
>
> 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).

I'm suprised you say "all the necessary fields", because a tm contains no
info about timezone.  C99 introduces a struct tmx that does.  The initial
segment of a struct tmx must be identical to a struct tm, but the meaning of
tmx.tm_isdst differs from tm.tm_isdst.  tmx.tm_isdst

    is the positive number of minutes of offset if Daylight Saving
    Time is in effect, zero if Daylight Saving Time is not in effect,
    and -1 if the information is not available.

Then it adds some fields not present in a struct tm:

    int tm_version;  // version number
    int tm_zone;     // time zone offset in minutes from UTC [-1439, +1439]
    int tm_leapsecs; // number of leap seconds applied
    void *tm_ext;    // extension block
    size_t tm_extlen;// size of the extension block

The existence of tm_version, tm_ext and tm_extlen can be fairly viewed as a
committee's inability to say "no" <wink>.

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