31–40 of 80 posts
It's unfortunate that Go's time library cannot represent an infinite duration, or timestamps in the infinite past or infinite future. This makes it difficult to represent things like "this cache entry never expires", without relying on auxiliary data. Also, the minimum/maximum timestamp and overflow behavior seem to be poorly-defined.
It's unfortunate that Go's time library cannot represent an infinite duration, or timestamps in the infinite past or infinite future. This makes it difficult to represent things like "this cache entry never expires", without relying on auxiliary data. Also, the minimum/maximum timestamp and overflow behavior seem to be poorly-defined.
You could use the zero value (t.IsZero()) for that if you wanted to. That might be more confusing than a boolean flag though.
It's also not a great idea to manually define the largest possible timestamp as a sentinel, because Add(Duration) doesn't check for overflow.
It's unfortunate that Go's time library cannot represent an infinite duration, or timestamps in the infinite past or infinite future. This makes it difficult to represent things like "this cache entry never expires", without relying on auxiliary data. Also, the minimum/maximum timestamp and overflow behavior seem to be poorly-defined.
It's unfortunate that Go's time library cannot represent an infinite duration, or timestamps in the infinite past or infinite future. This makes it difficult to represent things like "this cache entry never expires", without relying on auxiliary data. Also, the minimum/maximum timestamp and overflow behavior seem to be poorly-defined.
You can use nil to represent "no expiration."
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 li…
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…
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...
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 li…
"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.
Earlier 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…
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'm surprised about the method to define a time format by example. There could be an ambiguity between month and day if the example is badly chosen. I prefer the C way with the struct and format. How do I get the time offset to UTC time at a given date and location ?
Looks like you could do this: http://play.golang.org/p/Lq3xv6f-PI
I'm surprised about the method to define a time format by example. There could be an ambiguity between month and day if the example is badly chosen. I prefer the C way with the struct and format. How do I get the time offset to UTC time at a given date and location ?
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.
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.