My favorite is time.Ticker: It returns a channel of Time objects, dispensed at intervals of your choice. It even auto adjusts the interval based on how long your receiver takes to run.
Time in Go
41–50 of 80 posts
Re: Time in Go
#42Earlier 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…
> 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.
Re: Time in Go
#43More 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…
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]
Re: Time in Go
#44fmt.Printf("\n... and %v days after that ...\n", days) t2 := t1.Add(time.Duration(days) * time.Hour * 24) printTime(t2) How is that supposed to work with daylight saving time? Won't t2 end up one hour off from t1 if there is a daylight saving shift?
I find it easier to think of times in UTC rather than local timezones. In UTC (and in reality), those times will always be the same number of hours distance from each other. If you format it in different timezones (PDT and PST) then yeah, the formatted times will be at different hours of the day.
That's not true for UTC, you'd need TAI for that. UTC includes leap seconds.
Re: Time in Go
#45Slightly offtopic but I always thought that Mike Bostock's bl.ocks.org was created to support D3 visualization sharing. This is the first time I see it used for another language, somewhat contrary to it's designed use.
Re: Time in Go
#46Earlier 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 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.
Re: Time in Go
#47Earlier 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. The date is not easy to remember
not easy to remember or just unfamiliar?
> 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 ?
is that not `3`?
> I guess I should than use my own formatting instead of predefined formating.
what do you mean?
some common formats are defined here and how it all works is described there as well https://golang.org/pkg/time/#pkg-constants it also mentions https://golang.org/pkg/time/#Time.Format (click the `> Example`)
Re: Time in Go
#48Earlier quoted context omitted.
True, and for most cases the parsing is great too, but once you get off the beaten path of standard time formats, parsing times can be annoying.
Do you have any examples of annoying to parse time formats?
I remember we had the same problem parsing time formats. Can't remember any specifics though (might have been timezone offsets), but I think parsing would be less error prone when there wouldn't be that magic date time formatting by example style used.
I can totally understand that it is often easier to use, but compatibility with strftime is good for the experienced developer. There is a reason, why sites like [1] and several 3rd party libs [2] exist.
[1]: http://fuckinggodateformat.com/
[2]: https://github.com/search?q=language%3Ago+strftime&ref=searc...
Re: Time in Go
#49More 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…
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)
Re: Time in Go
#50It'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.
I believe the idiomatic way would be to have 2 "Add" functions:
func (c *Cache) AddExpiring(k Key, e Entry, d time.Duration) {}
func (c *Cache) Add(k Key, e Entry) {}
func (c *Cache) GetWithRemaining(k Key) (e Entry, left time.Duration) {}