Comment by stillpointlab
Comment by stillpointlab 6 months ago
That is good context, thanks! Once I found my bug I had a moment of not being sure who to blame. Honestly, I'm a bit surprised that the ISO8601 spec dictates that absent the Z the date-time ought to be interpreted as local. At the least, I expected there would at least be a way for me to say "trust me JS, this date is UTC so please parse it that way" - but the only way I could find to force that to happen was to manually add a "Z".
But the insanity of inconsistently choosing local/UTC based on the presence of time is genuinely painful. Dates and times are hard enough as it is, why would they do that? It gives me some amusement that this was one of the motivating use cases behind the Temporal spec.
> I'm a bit surprised that the ISO8601 spec dictates that absent the Z the date-time ought to be interpreted as local
My understanding is that an ISO8601 timestamp with no offset simply means that no time zone is specified, like what the JS Temporal API calls a PlainDateTime. This is a reasonable concept, and to avoid footguns it should be impossible to implicitly convert such a timestamp to a timestamp with a time zone.
This concept isn’t representable as a JS Date, which will always have a time zone specified (always the local time zone).