> time.Duration(mins) * time.Minute
Seems a bit clunky. Why not time.FromMinutes(mins) or something to that effect? time.Duration is just "casting" an int64 to a Duration type?
Time in Go
71–80 of 80 posts
Re: Time in Go
#72> time.Duration(mins) * time.Minute Seems a bit clunky. Why not time.FromMinutes(mins) or something to that effect? time.Duration is just "casting" an int64 to a Duration type?
Yes.
That's why you usually write it like this:
time.Now().Add(10 * time.Minute)Re: Time in Go
#73Earlier quoted context omitted.
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.
Re: Time in Go
#74Earlier quoted context omitted.
Then I think it is not very convenient to type out strings like "America/Los_Angeles" when you are dealing with timezones that come with abbreviations only. The whole point of using abbreviations is to avoid typing out the full name. Unless there is a way to get "America/Los_Angeles" from "PST"
Yeah, I don't get why they require a location. On the other hand, -0700 isn't much longer than PST and parses directly.
Abbreviations are reused in different locales. PST in one locale can have different rules than PST in another locale. The reason the fully qualified name is needed is because it uniquely identifies a locale for which timezone rules can be followed.
Offsets aren't always the right thing to use either. If you are in America/Chicago and use -0600 for your timezone, that's only accurate during standard time, and is off by an hour for daylight savings time. Knowing how/when to shift offsets is part of the timezone rules associated with a locale, because they are not constant historically.
Re: Time in Go
#75Earlier quoted context omitted.
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 qu…
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.
Re: Time in Go
#76Earlier quoted context omitted.
If you use time zones without offsets (just the name like PST instead of -0700) then you have to parse the time in a specific location http://play.golang.org/p/JzKAq09NtE I can only assume that the time zone name alone is insufficient to resolve ambiguous times.
Then I think it is not very convenient to type out strings like "America/Los_Angeles" when you are dealing with timezones that come with abbreviations only. The whole point of using abbreviations is to avoid typing out the full name. Unless there is a way to get "America/Los_Angeles" from "PST"
I mentioned this elsewhere in this thread, but abbreviations are not unique across timezones. The rules for timezones change based on locale, and if you have multiple zones with PST as an abbreviation, which one do you use? It has to be an explicit choice or it's almost certainly going to be wrong. There is no way to get America/Los_Angeles from PST without knowing the locale that the date and time is from.
Re: Time in Go
#77Earlier quoted context omitted.
Yeah, I don't get why they require a location. On the other hand, -0700 isn't much longer than PST and parses directly.
Abbreviations are reused in different locales. PST in one locale can have different rules than PST in another locale. The reason the fully qualified name is needed is because it uniquely identifies a locale for which timezone rules can be followed. Offsets aren't always the right thing to use either. If you are in America/Chicago and use -0600 for your timezone, that's only accurate during standard time, and is off b…
Ah thanks, that confirms my theory of why the location is required to parse time zone names like PST.
Offsets are probably going to be fine for recorded timestamps, if all you need is the absolute time that the timestamp represents. But yeah, timezones make things so complicated that there is no one true solution I guess.
Re: Time in Go
#78Re: Time in Go
#79Earlier 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…
> 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
Re: Time in Go
#80Earlier 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'.
.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.