Maybe this is a documentation issue but I currently look at a situation where I have ISO time strings of the variants:
2026-02-12T20:17:23-05:00
2026-02-12T17:36:59Z
2026-02-12T17:36:59Z is obvious. It's directly in UTC and parses as such.
2026-02-12T20:17:23-05:00 only parses as zoned time`.
This seems both annoying and perhaps wrong. Best I understand it something like 2026-02-12T12:17:23-05:00 is a UTC time. Namely it's ``2026-02-12T17:17:23Z`. And it doesn't really specify a time zone (after all one offset can be shared by multiple timezones so at best it would be ambigous).
For clarity I understand having the default UTCTime parser reject 2026-02-12T20:17:23-05:00 but it would be imo both useful and correct to have a parser that allows offsets but parses into UTCTime.
Concretely I suggest adding something with semantics similar to parseUTCAnyOffset s = (zonedTimeToUTC <$> iso8601ParseM s) <|> iso8601ParseM s but a better implementation.
Maybe this is a documentation issue but I currently look at a situation where I have ISO time strings of the variants:
2026-02-12T17:36:59Zis obvious. It's directly in UTC and parses as such.2026-02-12T20:17:23-05:00only parses as zoned time`.This seems both annoying and perhaps wrong. Best I understand it something like
2026-02-12T12:17:23-05:00is a UTC time. Namely it's ``2026-02-12T17:17:23Z`. And it doesn't really specify a time zone (after all one offset can be shared by multiple timezones so at best it would be ambigous).For clarity I understand having the default UTCTime parser reject
2026-02-12T20:17:23-05:00but it would be imo both useful and correct to have a parser that allows offsets but parses into UTCTime.Concretely I suggest adding something with semantics similar to
parseUTCAnyOffset s = (zonedTimeToUTC <$> iso8601ParseM s) <|> iso8601ParseM sbut a better implementation.