[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>.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4