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