Steve Summit wrote: >And this is eerily similar to the idea of using a struct >timespec with a nonnormalized tv_nsec field.
For that matter, tm_sec==60 is the same class of trick too. We're just varying at which digit position we stuff in an out-of-radix value. > the UTC-aware son-of-time_t representation I've been >exploring using the pair (days since 1970, seconds within day).) I've used (days-since-epoch, seconds-since-midnight) representations too. The (MJDN, MJDF) tuple is precisely equivalent to that, just with the time-of-day scaled. (I like to use bignum-ratio representations of MJDF, rather than floating point, so that it can exactly represent integral seconds.) This class of representation is really the most natural way to approach UTC: its fundamental units are the days and the seconds, so just counting both of those works nicely. >Now that's a cute idea. (But when you say "It's tempting", >do you really mean "It's tempting, but don't do it"? :-) ) If actually implemented, the extreme rarity of the "A" digit would tend to make it confusing. It's much weirder than ":60". Another thing that puts me off is that there's no equivalent trick for a timezone-relative CJD, where the leap second could arise at any minute of the day. For that matter, it doesn't even translate nicely to JD, where one could introduce an extra digit, but it would be duplicating the "5" digit rather than having a novel value. So although the trick works for the specific case of MJD, it gets no support from its conceptual context, and I'm dubious about the value of a mechanism so exceptional. That's the cause of a lot of the trouble we have with leap seconds. The (MJDN, MJDF) tuple and equivalents, by contrast, make the leap second look a lot less exceptional. -zefram _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
