Tim Peters wrote: > > 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>. FYI, mxDateTime test the C lib for leap second support; if leap seconds are used, then it has to support these too in conversions from and to Unix ticks. > 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>. What strange about leap seconds is that they don't fit well with the idea of counting seconds since some fixed point in history. They are only useful for conversions from this count to a broken down date and time representation.... time simply doesn't leap. >From a comment in mxDateTime: /* This function checks whether the system uses the POSIX time_t rules (which do not support leap seconds) or a time package with leap second support enabled. Return 1 if it uses POSIX time_t values, 0 otherwise. POSIX: 1986-12-31 23:59:59 UTC == 536457599 With leap seconds: == 536457612 (since there were 13 leap seconds in the years 1972-1985 according to the tz package available from ftp://elsie.nci.nih.gov/pub/) */ -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
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