In the last company I work for, the department was created from zero, and my boss just let me take all the technical decisions so from the begging everything was wrote in ISO-8601. When I left it was just the way it was, if you try to use any other date format anywhere something is going to give you an error.
This is the way.
Feb 27th 2013
Boom. Everything is in a different format so you can order it however you want and it’s still readable.
Why use abbreviations in your preferred language when you can have a solution that is language-agnostic and universal (for a given calendar) ?
Because if there’s one problem simple enough that I trust an LLM or translation app not to fuck up, it’s simple translation of month labels from on language to another. If you’re writing in English, it’s reasonable to have month abbreviations in English. If someone wants to read it in a different language, they’re going to have to use translation software or hire a human translator to do it. And regardless of translation method, simple date translation will be among the most reliable and faithfully translated parts.
10:13 PM on February 27th, but how do you write the year?
10:13 would be 2213 ?
I’m a fool
So, assuming you got the time wrong and meant you could confuse year and time of day, ISO also puts time after date.
2025-05-01T18:18:03Z
Which makes sense. Higher unit to lower unit.
10:13pm or 8:13pm? I can see how this is confusing… perhaps another cartoon with more guidance might be needed.
Personally I like date time groups: 272013 Feb 2013
That format near the cat’s tail should have used hue to differentiate year/month/day…
It’s the only way.
There is still confusion to be had before 1582-11-29
The sane way of dealing with it is to use UTC everywhere internally and push local time and local formatting up to the user facing bits. And if you move time around as a string (e.g. JSON) then use ISO 8601 since most languages have time / cron APIs that can process it. Often doesn’t happen that way though…
Generally yes, that’s the way to do it, but there are plenty of times where you need to recreate the time zone something was created for, which means additionally storing the time zone information.
Definitely. If your servers aren’t using UTC, then when you’re trying to sync data between different timezones, you’re making it harder for yourself.
This is what I try to do in the few apps I’ve written that had to deal with dates and times
The BEST way is to use the number of seconds after the J2000 epoch (The Gregorian date January 1, 2000, at 12:00 Terrestrial Time)
ISO 8601 goes from 1582 (Julian calendar adoption) but can go even further with agreement about intention and goes down beyond the millisecond. Not sure why I want an integer from the year 2000 which only represents seconds.
deleted by creator
I think you skipped part of the sentence.
Working for a global clinical research company, DD-Mmm-YYYY is the easiest for everyone to understand and be on the same page. It’s bad enough identifying which date you’re capturing in metadata without also trying to juggle multiple date formats.
@m_f@discuss.online this might be applicable to the farside as well
Do you mean the post titles? I’ve been using the same format as was used since before I took over posting, but if people want ISO format that works for me
I’m all for ISO format. I can’t imagine anyone having objections.
Posting in ISO format now, we’ll see if there’s any objections
Everyone should use date-time groups so we’re all on the same page down to the second.
DDHHMMSSZmmmYY
%Y%m%dT%H%M%SZ
Disregard ISO8601. Acquire RFC3339. You can leave off the T if you want to, or replace Z with
+00:00.with ISO 8601:
Sure, how about 2018-W06-1? Or 2018-036?
ISO 8601 contains way too many obscure formats. RFC 3339 is pretty much a subset and defines only sensible ones. It also allows 2018-02-05 08:02:43-00:00 (no T and explicitly specifying no timezone)
Acquiring the document (legally) to ensure compliance for ISO 8601 is relatively expensive for a single person (~$200 USD), while RFC 3339 is accessible for free.
I’m working in an international company with colleagues around the world. To avoid confusion, I switched to using this format:
27-FEB-2013
I deal with a lot of old records and boy I really prefer iso when you have to look at a lot of dates and things are in all different years, it’s helpful. Have you tried ISO? I also do a lot of international work and haven’t heard complaints about it being confusing.
Sounds like something a terrorist would say.
As a Hungarian, I approve.
As an American, I can’t get people in my team to standardize their email signatures with correct spelling.
This format can fuck off. I prefer the unambiguous format 2FEB2013.
Checkmate, date snobs.
And yes, nations are free to use their appropriate abbreviations for the months.
