Java is an excellent example of how not to do date/time APIs (pre Java 8 anyway). My answer (from years ago):
Time in Go
61–70 of 80 posts
Re: Time in Go
#62Earlier quoted context omitted.
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…
> 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'.
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.
Re: Time in Go
#63Earlier quoted context omitted.
> 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'.
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). :-)
Re: Time in Go
#64Earlier quoted context omitted.
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…
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?
Re: Time in Go
#65Earlier quoted context omitted.
> 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'.
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.
> Chrono is pretty good.
Re: Time in Go
#66Earlier quoted context omitted.
There is no ambiguity - you are to provide predefined date in your layout. That predefined date (Mon Jan 2 15:04:05 -0700 MST 2006) is chosen in a way so that there is no ambiguity.
Thanks for the clarification. That info was missing in the date API presentation. Indeed, there is no ambiguity. Just two comments: 1. The date is not easy to remember 2. There is still an ambiguity with hours representation. What if I want to represent hours without a leading 0 for values smaller than 10 ? I guess I should than use my own formatting instead of predefined formating.
You can remember it as 1 2 3 4 5 6 7: First month, second day, 3pm and four minutes and five seconds in the year '06, offset -7.
Re: Time in Go
#67Earlier quoted context omitted.
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…
> 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'.
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.
Re: Time in Go
#68Earlier quoted context omitted.
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…
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…
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.
Re: Time in Go
#69Earlier quoted context omitted.
There is no ambiguity - you are to provide predefined date in your layout. That predefined date (Mon Jan 2 15:04:05 -0700 MST 2006) is chosen in a way so that there is no ambiguity.
Thanks for the clarification. That info was missing in the date API presentation. Indeed, there is no ambiguity. Just two comments: 1. The date is not easy to remember 2. There is still an ambiguity with hours representation. What if I want to represent hours without a leading 0 for values smaller than 10 ? I guess I should than use my own formatting instead of predefined formating.
1. http://strftime.org/ is not easy to remember
2. You could format it with a placeholder for the hours, then replace the placeholder with the hours you want. Oddly this is only a problem for 24 hour time, 12 hour time lets you drop the leading zero.
Re: Time in Go
#70Earlier quoted context omitted.
Looks like you could do this: http://play.golang.org/p/Lq3xv6f-PI
Is there a "method" to get day light saving as well ? The possibility to get a loc object is great and missing in the C API. I guess/hope it encapsulate all the info found in the tz database.
You might just want to use the tz info database directly.