5 ms·

More languages should copy Go's time library. As someone who has written a lot of Go for years, I am always very quick to say that "time" is my favorite Go sta

More languages should copy Go's time library. As someone who has written a lot of Go for years, I am always very quick to say that "time" is my favorite Go standard library. I love it. The "time" library is to Go what the "requests" [non-standard] library is to Python, in terms of a great API and simplicity. For some reason in every other language I've used (important, I don't know every time library! :P) the time library has always been adequate, but not much else. I think Python's "datetime" is a great example of a not great time library. At one point I was writing Python every day for a couple years. During that time, I could never ever remember the API for datetime, despite it being able to do what I needed to do well enough. I always had to open the docs. I think this is an example of an adequate library that just doesn't have a great API. Or, take the more generic problem of: I have a time, I have a duration, how do I tell if that duration has passed? Most developers I know (including myself) stumble on this for some period of time (see what I did there?), remembering what do I add to what and is it a greater than or a less than or do I subtract, etc. It is an easy problem, but always seems to require a little bit of thinking. Go's "time" library is nothing like this. Go's "time" library you will remember the API, it is intuitive. You can even guess it after writing Go for some period of time. It is that easy (ignoring the constants and non-standard printf-like function in it). Go's "time" comparison/arithmetic is incredible. Comparing times? Determining expiration? You'll almost never get this wrong the first time. (But write tests anyways) 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.

ioddly 11y ago
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.
- deleted 11y ago
  [deleted]
- XorNot 11y ago
  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.
AdieuToLogic 11y ago
> 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 http://joda-time.sourceforge.net/userguide.html 2 - http://www.boost.org/doc/libs/1_59_0/doc/html/date_time.html 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/examples.html#date_time.examples.time_periods http://www.boost.org/doc/libs/1_59_0/doc/html/date_time/exam...
jcranmer 11y ago
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.
- enneff 11y ago
Animats 11y ago
"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 https://bugs.python.org/issue15873

ioddly 11y ago

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.

deleted 11y ago
[deleted]
XorNot 11y ago
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.

AdieuToLogic 11y ago

> 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 http://joda-time.sourceforge.net/userguide.html 2 - http://www.boost.org/doc/libs/1_59_0/doc/html/date_time.html 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/examples.html#date_time.examples.time_periods http://www.boost.org/doc/libs/1_59_0/doc/html/date_time/exam...

jcranmer 11y ago

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.

enneff 11y ago

Animats 11y ago

"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 https://bugs.python.org/issue15873