Live data from Hacker News

Time in Go

bl.ocks.org

21–30 of 80 posts

Re: Time in Go

#21
post #10

Earlier quoted context omitted.

I can find it later, but I just had this issue this week with timestamps sent from a browser, supposedly in RFC3339, but Go's RFC3339 format was not compliant with it. So naturally I made my own format template. Alas, the milliseconds part had arbitrary precision, which Go's parser doesn't like. So I had to revert to trying the timestamp with one, two ,three trailing digits, etc. Still, this is the only issue I have…

I wasn't able to reproduce this issue, time.Parse(time.RFC3339Nano, "2015-09-10T06:31:39.442Z") seems to work correctly as long as the number of digits between "." and "Z" is 0-9

The problem is that the browser sends it in a different format (it's the HTML5 date-time input), 3399 simplified or something like that. So I ended up doing something like:

> formats := []string{ string(time.RFC3339), "2006-01-02T15:04:05.0", "2006-01-02T15:04:05.00", "2006-01-02T15:04:05", "2006-01-02T15:04",}

To make sure I have all cases covered

Re: Time in Go

#22
post #7

Earlier quoted context omitted.

http://play.golang.org/p/hCoZ3tdeM_ am I doing this correctly? Because it seems that golang does not recognize the abbreviations at all.

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"

Re: Time in Go

#23
post #12

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

Re: Time in Go

#24
post #9

So I copied the example from http://golang.org/pkg/time/#Parse and it did NOT work as expected: http://play.golang.org/p/Xd9oEeSffd (timezone offset is zero)

This works correctly if your locale includes the PST timezone (works fine on my computer). They should probably have a better example though.

By "works fine" you mean in your local environment or the go playground?

Because it could potentially cause problems if the execution result varies from geographical locations and user's environment. I for one have no idea if my computer has a locale that includes PST timezone.

Re: Time in Go

#25
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.

Re: Time in Go

#26
post #16

fmt.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.

Re: Time in Go

#27
post #25

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.

Re: Time in Go

#28

Earlier quoted context omitted.

This works correctly if your locale includes the PST timezone (works fine on my computer). They should probably have a better example though.

By "works fine" you mean in your local environment or the go playground? Because it could potentially cause problems if the execution result varies from geographical locations and user's environment. I for one have no idea if my computer has a locale that includes PST timezone.

Sorry I meant in my local environment.

It's clear that the execution varies, as Parse(), unlike ParseInLocation() depends on the local environment, and play.golang.org probably uses some UTC locale.

Re: Time in Go

#29

Earlier 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"

Yeah, I don't get why they require a location.

On the other hand, -0700 isn't much longer than PST and parses directly.

Re: Time in Go

#30

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 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.

Post reply on HN