search

haskell / time

A time library
http://hackage.haskell.org/package/time
Other
119 stars 79 forks source link

Timestamps with large offsets are not parseable #161

Closed NorfairKing closed 3 years ago

NorfairKing commented 3 years ago

I'm not sure if this is time's fault. (I'm pretty sure it's not), but a timezone with a large offset does not roundtrip:

    test/Smos/Data/TypesSpec.hs:53
  ✗ 2 Smos.Data.TypesSpec.parseTimestampString.parses whatever timestampString outputs
      Failed after 1 tests and 27 shrinks
      Generated: TimestampZonedTime 1858-11-17 00:00:00 +92185683903
      Failed to parse: "1858-11-17 00:00:00+921856839:03" to TimestampZonedTime 1858-11-17 00:00:00 +92185683903

Is there an undocumented constraint that the Int offset must be within [-1439 .. 1439]?

NorfairKing commented 3 years ago

Correlary:

When there are UTF16 suggorate codepoint characters in the timezone name, exceptions are thrown in pure code!

NorfairKing commented 3 years ago

Gentle ping

AshleyYakeley commented 3 years ago

When parsing, time zones must be in ±HHMM or ±HH:MM format.

Could you tell me the use case for a time zone of (checks post) 921856839 hours and 03 minutes ahead of UTC?

NorfairKing commented 3 years ago

@AshleyYakeley The type allows for such a timezone and does not document any validity constraints, so property testing generated a very weird timezone :D. (I guess the library checks for that the number of hours is maximum double-digits but still.) I'd be happy with just some document validity constraints. If we document "Timezone offsets must be within [-1439 .. 1439]" then that would be fine.

AshleyYakeley commented 3 years ago

The relevant constraint is not on the type per se, it's on parsing functions, that time zones must be in ±HHMM or ±HH:MM format.

That constraint is documented. If you're going to be parsing time-zones, you need to fix your testing accordingly.

NorfairKing commented 3 years ago

@AshleyYakeley Fair enough! So the rendering and parsing doesn't roundtrip on purpose. I'll consider this "broken as intended" then?

AshleyYakeley commented 3 years ago

I'm not sure what you think is broken. The TimeZone type cannot be round-tripped through formatting/showing and parsing, since show does not write out all the information in the type. This is documented in the haddock at Read TimeZone and Show TimeZone.

NorfairKing commented 3 years ago

@AshleyYakeley Super, thanks!