Preserving offsets

[jweir]

Nice to see this, much, much cleaner than what I created https://github.com/jweir/elm-iso8601/tree/parser

My applications display time based data across several timezones. The application graphs this data in the local time, sometimes comparing the data across timezones and often grouping the data relatively (ie all points by hour, or day of week.)

Once the time is converted to POSIX, the local time is of course lost. It can be converted back if the application is aware of the timezone/offest of the source data. But this would become an extra step left to the libraries consumer.

If the application gets a point like this { t: "2006-07-08T09:10:11.123-05:30", v: 7} how will the application ever cast it back to local time?

What I propose, to keep this library as light as possible, is one new function like:

-- offset is the number of seconds?
type alias Offset = Int 

toTimeAndOffset : String -> Result Parser.Error (Time.Posix,Offset)

Then the library consumer can make the necessary calculations on the time to present in the local format.

I'd be happy to take a stab at a PR if you think this would be appropriate.

[rtfeldman]

So I have some pretty strong feelings about UTC Offset. Specifically, I feel it was a tragic mistake for any technology ever to have adopted it. To me, chucking the ISO-8601 dates' UTC offsets into the incinerator is a great feature, and it's one I'm reluctant to consider removing. 😅

The trouble with UTC Offset is that it isn't the same as time zone, but applying UTC offset coincidentally gives the same answer as applying a time zone just often enough to instill a false sense of confidence and let edge case bugs slip under the radar.

Put more concisely, UTC Offset is a subtle bug factory. It's very frustrating to me that browsers only expose UTC Offset for the current user, rather than exposing actual timezone information.

Anyway, given the use case of wanting to send timestamps along with time zones, I personally wouldn't use UTC Offset for that, which means I wouldn't use ISO-8601 dates for that either. I would rather send the timestamp along with the actual time zone!

[jweir]

Fair enough – I understand your motivation, and I agree the TZ is the correct choice over offset.

I would rather send the timestamp along with the actual time zone!

If you have the luxury of controlling the source of the data. Imagine getting a blob of timestamped data across several timezones and you need to analyze it by local hour or day of week. The data only comes in ISO-8601 (you can not control the source). Without the offset your task is going to be very difficult.

Something to consider.

I will close this issue as there are alternatives for my use case.

Cheers and thank you!