4 ms·
So what's a better time library? Or, rather, how could Go's time library better accommodate these things? It's also not clear that a standard library time packa
by enneff 11y ago
So what's a better time library?
Or, rather, how could Go's time library better accommodate these things?
It's also not clear that a standard library time package should be the be-all, end-all time management solution. I don't see any reason for a standard time package to handle historical dates, for example.
Google found a nice solution to the leap second issue: we "smear" the second over the day before it occurs by making tiny changes to the time over the day. This means user applications don't need to be aware of it: http://googleblog.blogspot.com.au/2011/09/time-technology-and-leaping-seconds.html http://googleblog.blogspot.com.au/2011/09/time-technology-an...
- Animats 11y agoThe power grid people do that, but after the leap second. It takes about four hours, as every 1800 RPM synchronous motor and generator on the grid makes 30 extra turns.
- masklinn 11y ago> So what's a better time library? JSR 310/Project Kenai/Joda Next is often held up as the gold standard of complete, correct datetime handling.
- draegtun 11y agoAnd I would also add Perl's DateTime library to this list - https://metacpan.org/pod/DateTime https://metacpan.org/pod/DateTime
- simi_ 11y agoI was going to mention the same thing wrt leap seconds: if a company at Google's scale could apply a "hacky" solution to this, then you don't really need a more "scalable" solution. The fact that it simplifies things massively for the developers can be a turn off for some people, though.
- kibwen 11y agoYou've got it backwards: a company of Google's scale can do this because they're already providing and administering their own NTP servers. For a company of a smaller scale, that's an unnecessary cost. That said, I'm intrigued at the idea of a public NTP server that does Google-style leap-second smearing. Does anyone know if one exists?
- todd8 11y agoAll the Network Time Protocol servers that I know of handle leap-seconds in one way or another. Some do leap-second smearing and I believe that newer versions of NTPD and OpenNTPD both support smearing. However, it appears (with only a cursory examination) that the Google time servers start smearing before the actual leap second is inserted and I've never seen that done anywhere else (or I missed it by reading too quickly). See https://news.ycombinator.com/item?id=10199686 https://news.ycombinator.com/item?id=10199686 Also note that big changes in the way time is handled (leap seconds, etc.) in the near future because of the upcoming meeting of the International Telecommunication Union (ITU) at the World Radiocommunication Conference in November 2015.
- sla29970 11y agoThe ITU has 4 methods for dealing with leap seconds, and method D is to change nothing. See the lack of consensus for any change in last week's presentations at http://www.itu.int/en/ITU-R/conferences/wrc/2015/irwsp/2015/Pages/program.aspx http://www.itu.int/en/ITU-R/conferences/wrc/2015/irwsp/2015/... especially the "Input Document WRC-15-IRWSP-15/8" presentation by Zuzek.
- tel 11y agoHaskell's `time` (and its faster, lensier, API-compatible copy, `thyme`) handle these issues with aplomb and have been around a while. You'll also want to include timezone-series and timezone-olson for accurate TZ handling. https://hackage.haskell.org/package/time https://hackage.haskell.org/package/thyme https://hackage.haskell.org/package/timezone-series https://hackage.haskell.org/package/timezone-olson