The value of this didn’t really hit me until this line (which frankly should be the lede):
“This precision means that regardless of DST changes or any other local time adjustments, your date will always reflect the correct moment in time.”
Probably a failing on my part but I had somehow assumed all this time that calculating DST was a separate concern from time zone offset, given how tremendously opaque it can be.
To my knowledge, there is an area in Arizona that does observe DST, within an area that does not observe DST, within an area that does, within Arizona at large, which does not. Does this API really accurately represent this peculiar arrangement?
It looks like canonically there’s an America/Shiprock timezone but you’d think you’d need at least 4 to accurately represent the various areas.
> To my knowledge, there is an area in Arizona that does observe DST, within an area that does not observe DST, within an area that does, within Arizona at large, which does not. Does this API really accurately represent this peculiar arrangement?
What are you envisioning? That sounds like two timezones, with different regions belonging to one or the other. Does it matter to the API if two regions that aren't contiguous with each other share a timezone?
“This precision means that regardless of DST changes or any other local time adjustments, your date will always reflect the correct moment in time.”
Probably a failing on my part but I had somehow assumed all this time that calculating DST was a separate concern from time zone offset, given how tremendously opaque it can be.
To my knowledge, there is an area in Arizona that does observe DST, within an area that does not observe DST, within an area that does, within Arizona at large, which does not. Does this API really accurately represent this peculiar arrangement?
It looks like canonically there’s an America/Shiprock timezone but you’d think you’d need at least 4 to accurately represent the various areas.
https://upload.wikimedia.org/wikipedia/commons/3/38/AZNMUT_D...