4 ms·

Do you have any examples of annoying to parse time formats?

paradite 11y ago
http://play.golang.org/p/hCoZ3tdeM_ http://play.golang.org/p/hCoZ3tdeM_ am I doing this correctly? Because it seems that golang does not recognize the abbreviations at all.
- deleted 11y ago
  [deleted]
- nulltype 11y ago
  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 http://play.golang.org/p/JzKAq09NtE I can only assume that the time zone name alone is insufficient to resolve ambiguous times.
  - paradite 11y ago
    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"
    - nulltype 11y ago
      Yeah, I don't get why they require a location. On the other hand, -0700 isn't much longer than PST and parses directly.
      - bitwalker 11y ago
        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.
        nulltype 11y ago
        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.
    - bitwalker 11y ago
      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.
- deleted 11y ago
  [deleted]
dvirsky 11y ago
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 with the time library, and even that has only bothered me a couple of times in 3 years of work, so no biggie. Other than that it's indeed the best time library I've ever worked with.
- nulltype 11y ago
  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
  - dvirsky 11y ago
    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
rmetzler 11y ago
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/ http://fuckinggodateformat.com/ [2]: https://github.com/search?q=language%3Ago+strftime&ref=searchresults&type=Repositories&utf8=%E2%9C%93 https://github.com/search?q=language%3Ago+strftime&ref=searc...

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

deleted 11y ago
[deleted]
nulltype 11y ago
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 http://play.golang.org/p/JzKAq09NtE I can only assume that the time zone name alone is insufficient to resolve ambiguous times.
- paradite 11y ago
  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"
  - nulltype 11y ago
    Yeah, I don't get why they require a location. On the other hand, -0700 isn't much longer than PST and parses directly.
    - bitwalker 11y ago
      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.
      - nulltype 11y ago
        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.
  - bitwalker 11y ago
    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.
deleted 11y ago
[deleted]

dvirsky 11y ago

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 with the time library, and even that has only bothered me a couple of times in 3 years of work, so no biggie. Other than that it's indeed the best time library I've ever worked with.

nulltype 11y ago
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
- dvirsky 11y ago
  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

rmetzler 11y ago

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/ http://fuckinggodateformat.com/ [2]: https://github.com/search?q=language%3Ago+strftime&ref=searchresults&type=Repositories&utf8=%E2%9C%93 https://github.com/search?q=language%3Ago+strftime&ref=searc...