ISO8601 is really broad with loads of edge cases and differing versions. RFC 3339 is closer, but still with a few quirks.
Not sure why we can't have one of these that actually has just one way of representing each instant.
Sometimes you need your timestamps to be in a named timezone. If I have a meeting at 9am local time next month, I probably want it to still be at 9am even if the government suddenly decided to cancel daylight time.
ISO8601 is really broad with loads of edge cases and differing versions. RFC 3339 is closer, but still with a few quirks. Not sure why we can't have one of these that actually has just one way of representing each instant.
Related: https://ijmacd.github.io/rfc3339-iso8601/
Always thought that a standard like ISO8601 which always stores the date and time in UTC but appends the local time zone would beneficial.
Sometimes you need your timestamps to be in a named timezone. If I have a meeting at 9am local time next month, I probably want it to still be at 9am even if the government suddenly decided to cancel daylight time.
unless the customer you're meeting is in another timezone where the government didn't cancel daylight time
I don't think I ever needed something like that... Since most cases don't need local time zone, why not keep two separate fields?
That would be solved if JSON had a native date type in ISO format.
JSON doesn’t really have data types beyond very simple ones