It’s not that simple. Parsing isn’t a problem, it’s formatting with a timezone that sucks. It’s a pinch point in a lot of different ways. Because MomentJS is in maintenance mode and the Temporal library isn’t ready yet, I tried to do it in vanilla JS. Date objects don’t do a good job of keeping track of timezone. You can only apply the timezone when converting the Date object to a string with .toLocaleString(locale, {timeZone: "America/New_York"}) and the formatting rules available are not capable of producing the desired not-quite-ISO8601Nanos timestamp (I don’t want it to be in UTC, I want that layout with a trailing timezone offset). I fell back to moment but moment-timezone doesn’t work well with the Jest tests as they’re written. I plan to rewrite a lot when the Temporal library is prod ready but that won’t be before this sprint is over.
What time format are you using? 64 bit Unix and date time strings should be easy to parse. Just a simple new Date(x).toLocaleString()
It’s not that simple. Parsing isn’t a problem, it’s formatting with a timezone that sucks. It’s a pinch point in a lot of different ways. Because MomentJS is in maintenance mode and the Temporal library isn’t ready yet, I tried to do it in vanilla JS. Date objects don’t do a good job of keeping track of timezone. You can only apply the timezone when converting the Date object to a string with
.toLocaleString(locale, {timeZone: "America/New_York"})and the formatting rules available are not capable of producing the desired not-quite-ISO8601Nanos timestamp (I don’t want it to be in UTC, I want that layout with a trailing timezone offset). I fell back to moment but moment-timezone doesn’t work well with the Jest tests as they’re written. I plan to rewrite a lot when the Temporal library is prod ready but that won’t be before this sprint is over.