[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/)