7 ms·
Pro tip: never ever use anything but ISO dates in UTC tz unless you're displaying it for a user in a UI.
by tluse 1y ago
Pro tip: never ever use anything but ISO dates in UTC tz unless you're displaying it for a user in a UI.
- xiconfjs 1y agoEven then it‘s ok :)
- nssnsjsjsjs 1y agoAnd unless you need the original date, time and time zone. Conversion to UTC is not injective e.g. when clocks change or politics happen
- deleted 1y ago[deleted]
- fnord123 1y agoRFC3339. ISO 8601 allows for 2 or 6 digit years. Truncating to 2 is just incorrect, and 6 digits is absurd. And you can read the RFC without paying ISO - and you can discuss the RFC with people who have also read it instead of relying on people using the Wikipedia page to interpret and explain ISO 8601. I have a scheduling service at work and I keep getting requests for implementing ISO 8601 timestamps but I ignore them. RFC3339 is the way forward.
- account42 1y agoPlus RFC3339 allows you to use a space instead of the ugly T delimiter between the date and time.
- jcul 1y agoThere's this handy venn diagram that I've seen floating around for a long time. Just found a random link to it with an image search: https://gyazo.com/d8517f72e24c38f055e17182842b991c/max_size/1000 https://gyazo.com/d8517f72e24c38f055e17182842b991c/max_size/... ISO 8601 does have some strange formats...
- badmintonbaseba 1y agoThat's a screenshot of this website: https://ijmacd.github.io/rfc3339-iso8601/ https://ijmacd.github.io/rfc3339-iso8601/
- jcul 1y agoThanks! That's where I remember it from.
- skissane 1y ago> ISO 8601 does have some strange formats... Not that I’ve ever really had cause to use it in anger, but I like the idea of ISO week dates. Effectively, the ISO weak year (often differs from the calendar year in the last week of December / first week of January), ISO week number and day of week form a leap week calendar - instead of having 365 days in a common year and 366 in a leap year, it has 364 days in a common year and 371 in a leap week year, with leap weeks (obviously) being less frequent than leap days. The Sym454 calendar [0] takes this idea further to create a perpetual calendar, with 12 months of 4 or 5 weeks; in leap years the 12th month is 5 weeks instead of 4 weeks long. However, the leap week rule proposed by Sym454 is different from that proposed by ISO 8601; the author of Sym454 argues his proposed rule has theoretical advantages (simple calculation and more uniform distribution of leap weeks). That said, there is a variant of Sym454 which uses the ISO 8601 leap week rule. [0] https://kalendis.free.nf/symmetry.htm?i=1 https://kalendis.free.nf/symmetry.htm?i=1
- Y_Y 1y agoI believe two-digit years haven't been allowed for a while: > ISO 8601:2000 allowed truncation (by agreement), where leading components of a date or time are omitted. Notably, this allowed two-digit years to be used as well as the ambiguous formats YY-MM-DD and YYMMDD. This provision was removed in ISO 8601:2004. (That's from https://en.wikipedia.org/wiki/ISO_8601 https://en.wikipedia.org/wiki/ISO_8601 - I don't have the standards handy, ironically.) Honestly I'm happy with either the RFC or ISO, but it seems like most normies haven't heard of RFCs so ISO is my default.
- fnord123 1y agoI believe you. But I haven't paid ISO for the pleasure of reading the actual spec so that passed me by.
- deleted 1y ago[deleted]
- realaleris149 1y ago> 6 digit years Totally insufficient for capturing important future events like the dead of the sun.
- 0points 1y agoProer tip: never use anything but unix timestamp until presentation.
- ainiriand 1y agoEven more proer tip: only use binary representations of variables until presented to the user.
- globular-toast 1y agoThis is great until someone asks whether a particular event happened before or after lunch.
- ryao 1y agoI always felt the answer to this question is both, since there is always yesterday and tomorrow as far as lunch is concerned, so everything by definition is both before and after lunch. Perhaps the question is ill formed and needs to ask if the time was before, during or after lunch, during the day of the timestamp while defining what during means. That would have a more normal answer.
- IAmBroom 1y agoThe question is clear. You are obfuscating it, for your own entertainment.
- ryao 1y agoIt is unclear to me. It has been ever since I was a child. This is what happens with periodicity. There is no 1 lunch reference point when you just say lunch in this sort of question.
- globular-toast 1y agoYou're not alone, believe me, but one of the things you have to learn at some point is that for the vast majority of the population the question is perfectly clear. This is an example of the midwit meme, something like this: IQ 55: it happened before lunch, IQ 100: "lunch" isn't a time, lunch for whom? And which lunch? Their first ever lunch? Do babies even have lunch? IQ 145: it happened before lunch.
- Scarblac 1y agoI disagree, store UTC time and the name of timezone it was originally recorded in so it can be translated back to that as well. UTC only loses information.
- jgalt212 1y agoYes, but whose timezone? The machine? The user? What about a machine to machine transaction?
- skissane 1y ago> and the name of timezone The problem is that can be difficult to portably determine. One wishes POSIX had an API “give me IANA time zone name for current process” which would do the needful to work it out (read TZ environment variable, readlink /etc/localtime, whatever else might be necessary)… but no, you are left to do those steps yourself. And it works reasonably well if the TZ environment variable is set, but it most commonly isn’t; readlink of /etc/localtime works on macOS and some Linux distros… but others make /etc/localtime a regular file not a symlink, which makes it all a lot harder And that’s POSIX. Then there’s Windows which is possibly the last platform to still use its own timezone database instead of IANA’s. Now, Unicode CLDR maintains a Windows-to-IANA mapping table… but you have to ship both that table, and maybe the IANA timezone DB too, with your app, and keep them updated I really wish Microsoft would ship the IANA database with Windows, and the IANA-Windows mapping table too, and provide APIs to query them, and keep them updated with Windows update. The core Windows OS and existing Windows apps can keep on using the legacy Windows TZ database for backward compatibility, whereas portable apps could use IANA instead if they wish
- tatersolid 1y ago> I really wish Microsoft would ship the IANA database with Windows, and the IANA-Windows mapping table too, and provide APIs to query them, and keep them updated with Windows update. I think they have done exactly what you describe for several years at least: https://learn.microsoft.com/en-us/dotnet/api/system.timezoneinfo.tryconvertwindowsidtoianaid?view=net-9.0 https://learn.microsoft.com/en-us/dotnet/api/system.timezone...
- sph 1y agoPro tip #2: never ever rely on automatic parsing of dates. It's a lie and will corrupt your data. Either use dedicated "from_iso8601" functions, or manually specify the format of the input string ("%Y%m%dT%H%M%SZ")
- j1elo 1y agoThe list of things that devs should "never ever" do grows by the day... turns out most things, even the simplest of things, even sometimes the most apparently trivial things (like naming of people, too) are in reality almost always much more complex and difficult to get right on the first go than expected. But then discussion ensues about how programmers these days add libraries as dependencies for almost everything! :-) I guess at some point a middle ground must be found.
- names_are_hard 1y agoWhat if you're storing a calendar date, such as a birthday? A timestamp is inappropriate, and it's meaningless to discuss timezones in this context. (Example - you want to know if a person is old enough to buy cigarettes, and you need to store a birthday that you can compare against the current day to see if they're legally 18 - if you store an epoch at UTC, do you store the time of day they were born? That's not the way the law works. Do you store midnight UTC? If they're currently in NY, can they but cigarettes at 7pm the day before their birthday because they're currently 18 in London?) Sometimes you need a logical calendar date, not a point in time in the history of the universe.
- rubslopes 1y agoAll solutions have problems, but I think UTC midnight is simpler than dealing with mixed date formats in the backend.
- ivan_gammel 1y agoIt’s 2025 and major backend stacks have domain-specific time types like LocalDate etc. Using them is the only correct and actually the simplest solution.
- mytailorisrich 1y agoIf you want to store a date you don't need to store a time, time zone, etc. and your question goes away. Certainly if you want to store birth dates and do age verification there is no point bothering with these issues, just store calendar date. Trivial to get date for age limit purposes.
- guffins 1y agoThat’s a great question. ISO 8601 doesn’t allow timezone offsets on date-only strings. If you were born in the US, can you buy cigarettes at 12:00 am on your 18th birthday in London? I’ve never heard of age verification laws caring what timezone you were born in. In fact, you couldn’t even pinpoint this from many people’s ID cards. Plenty of US states span multiple time zones, and I wouldn’t be that surprised if there were a maternity ward out there sitting on a TZ line.
- ulrikrasmussen 1y agoAnd if you need a date, then represent it as a date and not as a time point.
- dotancohen 1y ago> never ever use anything but ISO dates in UTC tz unless you're displaying it for a user in a UI. Not good for storing future meeting times. DST switchover dates can change, and your tz-normalized date won't change with it.
- mytailorisrich 1y agoTo me that an UI/UX issue. Internally everything is stored and handled in TAI (better than UTC as no discontinuity) and translated from/to something else for human consumption. I.e. for instance your should have logic to figure out what TAI period corresponds to "next month's meetings" if that's what the user wants, which you apply immediately on user inputs and then forget about DST, time zones, etc. in the rest of the code and storage. Another benefit is that if your user was in New York but is now in London it is trivial and well-constrained to adjust to local time.
- ezfe 1y agoUh, no - meetings need to be stored with a timezone they were created in. This is how major calendar apps work. In Apple Calendar you can enable advanced timezone settings and you get a timezone override option.
- deleted 1y ago[deleted]
- mzl 1y agoNo, it is not. It is because converting to UTC loses information that can't be retrieved.
- deleted 1y ago[deleted]
- saltcured 1y agoOr if you really want to be future proof, store the geolocation so you can try to figure out the jurisdiction for any changing regulations. Maybe they didn't change the date of the switch, but changed the timezone boundary on the map. But, then I guess we might need to account for fractured societies and actually store some kind of organizational code for which belief system the event author adheres to? :-)
- hughw 1y agoSome use cases really do require the local TZ offset be saved. Transforming everything to UTC wipes out that information. An engineer in the US reviewing industrial measurements logged in a plant in Asia from a variety of sources is definitely going to encounter lots of events recorded in local time. It would be maddening for that engineer to have to review and resolve events from different time coordinates, especially if they are doing the review months or years later. It's best to accept that reality and adopt local time as the standard. Then you must record the TZ offset per UTC in any new system you create.
- bbojan 1y agoYou mean you must record the timezone? Because the TZ offset can change throughout the year (e.g. due to daylight saving time).
- hughw 1y agoUsually the TZ offset is enough. The use case is a guy reading notes and logs from multiple sources. All that guy needs is to see the local time at the time and place of the event. So that, for example, he can match up the time stamp on some computer recorded log with the time some human operator recorded, in local time, on a paper record.
- davejohnclark 1y agoThere's a good post about why this isn't as foolproof an approach as it might first seem here https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/ https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a...
- christina97 1y agoThe post doesn’t account for the case where a suburb of Amsterdam breaks off from the rest of Netherlands and changes timezones… Then how do you know if the event was in the neighborhood or not? My point is that this is an extremely niche case and works around one particular type of timezone insanity. You either have a team dedicated to dealing with timezone insanity, or you store stuff in UTC.
- mzl 1y agoNo, but that is an even less likely situation, compared to the problems that the approach advocated for by Jon Skeet actually solves.
- mytailorisrich 1y agoTAI is even better as it is continuous without leap seconds.
- atoav 1y agoAnd ifnyou're displaying it in the Ui give users a date format option where ISO is the choice. I use ISO for everything and your software wrongly assuming I want a deranged lunatic date format based on some locale is not going to cut it. Locale is ok as a first guess, but maybe allow users tho make that choice?