Closed NorfairKing closed 3 years ago
Correlary:
When there are UTF16 suggorate codepoint characters in the timezone name, exceptions are thrown in pure code!
Gentle ping
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?
@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.
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.
@AshleyYakeley Fair enough! So the rendering and parsing doesn't roundtrip on purpose. I'll consider this "broken as intended" then?
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
.
@AshleyYakeley Super, thanks!
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:Is there an undocumented constraint that the
Int
offset must be within[-1439 .. 1439]
?