Hacker News Reader

Go's "time" library is deceptively simple. Time, in real life, is quite incredibly complex, and hiding that complexity from developers (as Go's library does) does them a great disservice.

To start with, there are actually two distinct notions of time: monotonic and wall-clock. In monotonic time, you want to measure time intervals with high accuracy: a second of monotonic time should correspond as much as possible to the physical span of a second (in the inertial frame of reference of the computer in question, because screw relativity). More importantly, when it's not possible to correspond that time, you at least want guarantees like "time never ticks backwards." In contrast, wall-clock time is about matching a (there's more than one, and the definitions can and do change unpredictably, possibly even retroactively) civil reference clock as accurately as possible.

If you mix those two notions of time, you can evidence problematic results--changing the system clock five months back, for example, caused my music player to suddenly stop playing music (most likely because a callback timer was scheduled on wall-clock time and therefore would be waiting a few hundred days to start playing again).

Which brings into the next obvious problem: leap seconds. Any span of time greater than 1 second is actually an ill-defined span of time in that it can have multiple values. Once every few years, a minute has 61 seconds (theoretically, it can also have 59, but that hasn't happened yet in practice). So if you're requesting to add a minute, do you really mean "add 60 seconds" or do you mean "add 1 to the minutes field"? POSIX (and anyone else who counts time as seconds since an epoch) opted to handle leap seconds by pretending they don't exist, which causes leap seconds to be so dangerous that, for example, the NYSE stopped trading for about an hour around the last leap second to avoid problems. I can personally attest to seeing date/time parsers choking on leap seconds. And it's not entirely clear if leap seconds actually exist in civil time in some jurisdictions, because there is a small amount of vagueness in the laws.

While on the topic of the differences between jurisdictions, do also note that, for historical dates, you really need to think about the difference between Julian and Gregorian calendars, as well as the fact that the date of adoption of the Gregorian calendar varies from country to country (thanks Protestant Reformation!). Oh, and the year didn't necessarily start on January 1, either, and the change from March 1 to January 1 happened differently for different countries and differently from the Julian->Gregorian adoptions.

Time is hideously complicated.

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-an...

The 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.

> 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.

And I would also add Perl's DateTime library to this list - https://metacpan.org/pod/DateTime

I 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.

You'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?

All 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

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.

The 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/... especially the "Input Document WRC-15-IRWSP-15/8" presentation by Zuzek.

Haskell'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

Agree with everything you said, but to add more lets talk about Timezones too! For example, I'm continually annoyed at the pervasive usage of US/* Timezones by engineers. I routinely have to bring up Arizona, but then I start to blow their mind when I get to Indiana. Usually by the time I bring up India and Nepal I've completely lost them and I don't even get a chance to bring up countries changing Timezones (or even crazier, changing whole days by "moving" themselves to the other side of the international date line)

I'd actually prefer to keep timezones out of the time library itself, and have them only part of string <=> time conversion. Basically move all TZ handling to the parse/format phase of input & output, with the understanding that times in the time lib are all UTC, all the time.

... because I've had to write TZ-handling code way too many times, on top of systems with poor support. Think "implement timezones in T-SQL" and you'll shudder along with me.

> Go's "time" library is deceptively simple.

Has any language initially shipped with a non-broken date / time library? (See: SQL, java, python,...)

Clearly a very hard thing to get right, but post-JodaTime there a fewer excuses for APIs like:

> AddDate(y, m, d) to add a given number of years, months, days:

which pretty much defines 'deceptively simple'.

.Net's is pretty good.

    var date = DateTime.UtcNow.AddDays(24).AddYears(-10);

In use:

   var billFor = 12; // months

   var firstDayOfMonth = DateTime.Today
       .AddDays(1 - DateTime.Today.Day);
    
   var billDates = Enumerable.Range(billFor)
       .Select(n => firstDayOfMonth.AddMonths(n));

I'm going to have to disagree. DateTime is pretty limited, especially when it comes to timezones. I highly recommend NodaTime instead.

With Rust, we pulled time out of the standard library before 1.0, specifically because we knew it wasn't up to the task. So if "no library" counts as a "non-broken" library...

We still don't have great libraries yet, but they're coming, slowly. Chrono is pretty good.

> With Rust, we pulled time out of the standard library before 1.0, specifically because we knew it wasn't up to the task.

This honestly strikes me a very good response. Saddling a still-growing community with sub-par core datatypes is worse than their absence.

> So if "no library" counts as a "non-broken" library...

Of course if I had phrased my question in terms of the 'first shipped date / time library' then Rust still has a chance to follow this illustrious trajectory for languages (i.e. really mess up). :-)

  > Chrono is pretty good.

For purposes of comparison to other libraries, here's a link to Chrono's documentation: https://lifthrasiir.github.io/rust-chrono/chrono/

Apple's date/time support (part of the Foundation framework in both iOS and Mac OS X) is fantastic. Better than anything else I've ever seen.

Erlang is an example of a language correctly handling these aspects, regarding time correction, drift, and so on: http://learnyousomeerlang.com/time

I think most language standard libraries just crib heavily off of the C interface, to their detriment.

Using a preset date (the 2006-01-02) instead of format strings was really inspired; it took me about 10 minutes of staring at the documentation to understand how it worked, but it's a lot more readable once you get it.

The only problem is the numbering scheme is brain dead because its based off a specific layout which isn't very sensible to start with.

They could've easily gone with something following significance and it would be much more memorable:

2006-05-04 03:02:01

But instead in gotime you write it with month and day out of order because they referenced this completely nonsensical format instead: Mon Jan 2 15:04:05 MST 2006

I can't remember this one for the life of me.

> What I'm trying to say is: even if you don't like Go, take a look at how Go's "time" library works. I think it would be valuable for other languages. Other languages can probably even do it better (imagining better type systems around units), but I've never seen an API that feels as right for manipulating time as Go's time stdlib.

Then you might be interested in Joda-Time[1] and Boost.Date_time[2]. I'm not saying they are better or worse than Go's time library. They are quite powerful in their own right however.

Taking the example you presented:

  take the more generic problem of: I have
  a time, I have a duration, how do I tell
  if that duration has passed?

In Joda-Time, it could look like (all types are in org.joda.time):

  new Interval (yourStartDate, theDuration).contains (
    candidate
    );

And in Boost.Date_Time (loosely based on this example[3]):

  date d = day_clock::local_day ();
  time_period allDay (ptime (d), ptime (d, hours (24)));

  if (allDay.contains (someTimeInstance)) { ... }

1 - http://joda-time.sourceforge.net/userguide.html

2 - http://www.boost.org/doc/libs/1_59_0/doc/html/date_time.html

3 - http://www.boost.org/doc/libs/1_59_0/doc/html/date_time/exam...

"I think Python's "datetime" is a great example of a not great time library."

"Datetime" is a bit strange at first, but not that bad. The parsing side is weak; I've been trying to get a parser for RFC3339 / ISO8601 timestamps into that library since 2012.[1] Sure, there are libraries for that in PyPi. There were four of them in 2012, all too broken to parse mail and RSS feed timestamps reliably. Now, there are six.

[1] https://bugs.python.org/issue15873