5 ms·
Amen. Particularly ISO8601.
by majkinetor 1y ago
Amen. Particularly ISO8601.
- yndoendo 1y agoAlways thought that a standard like ISO8601 which always stores the date and time in UTC but appends the local time zone would beneficial.
- theamk 1y agoI don't think I ever needed something like that... Since most cases don't need local time zone, why not keep two separate fields?
- Jenk 1y agoIt's a delimited string. There are many fields within that string already. "2025-07-10T09:48:27+01:00" That contains, by my quick glance, at least 8 fields of information. I would argue the one field it does not carry but probably should is the _name_ of the timezone it is for.
- tbrownaw 1y agoSometimes 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.
- jcelerier 1y agounless the customer you're meeting is in another timezone where the government didn't cancel daylight time
- Jenk 1y agoExchange/GMail/etc. already has this problem/feature. Their response is simple: Follow the organiser's timezone. If it's 9am on the organiser's calendar, it will stay at 9am on the organiser's calendar. Everyone else's appointment will float to match the organiser.
- PaulHoule 1y agoThere are a few things you want about dates. 1932-04-12 sorts lexically, 04/12/1932 doesn't. So long as you don't use a timezone or always use the same timezone (especially Z) you get this nice property with ISO 8601 which makes it better than the alternatives. Once you include timezones you get into all sorts of problems such as dates (as opposed to date times) only having a partial ordering as the day here in New York starts an hour earlier than Chicago. In an extreme case the Pearl Harbor attack was launched the day after it was executed. At some point you need real time aware libraries and whatever language you use they've been through several iterations of them (Javascript Date, moment, dayjs, ...) because they got it wrong the first time and probably the second time to. With ISO 8601 it is easy to get the yyyy, yyyy-mm, hh and other things you might work with primitive tools (awk). Getting the day of the week or the time involved is not hard which gets you to the chronological rosetta stone https://en.wikipedia.org/wiki/Julian_day https://en.wikipedia.org/wiki/Julian_day which is a multiplier and and offset away from Unixtime except for all those leap seconds and whatnot. With Unix timestamps comparison is easy and differences are easy and even knowing it is Thorsday is easy; they don't sort as strings but GNU sort has a -n option, only trouble is it is a bunch of twisty little numbers that look alike.
- Xenoamorphous 1y agoThat would be solved if JSON had a native date type in ISO format.
- SJC_Hacker 1y agoJSON doesn’t really have data types beyond very simple ones
- motorest 1y ago> JSON doesn’t really have data types beyond very simple ones What do you think primitive types are supposed to be?
- Jenk 1y agoThe below type definition (TS) fits the ECMA schema for JSON: type JSON = string | number | boolean | null | JSON[] | {[name: string]: JSON}
- SJC_Hacker 1y agoI guess my point was something like an ISO 8601 date would be beyond the scope of a built in data type given JSONs philosophy of a minimal spec. It’s up to the end user to define types like that.
- auszeph 1y agoISO8601 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/ https://ijmacd.github.io/rfc3339-iso8601/
- PaulHoule 1y agoI love how that's live! Since ISO 8601 costs 133 CHF I suspect hardly anybody has actually read it, I think if you wanted something that supports all the weird stuff you might find somebody wrote it in 390 assembly.