9 ms·
My favorite datetime format is "YYYY-MM-DD hh:mm:ss". I consider it the "Markdown for time". It is human-friendly and computer-friendly at the same time. It is
by mg 1y ago
My favorite datetime format is "YYYY-MM-DD hh:mm:ss".
I consider it the "Markdown for time". It is human-friendly and computer-friendly at the same time. It is supported by many languages and databases. It is so elegant and common that even though it is not part of a standard, LLMs started to use it when writing answers:
Me: SQLite: Add 1 day and 3 hours to a date.
Perplexity: SELECT DATETIME('2025-09-07 07:51:00', '+1 day', '+3 hours');
- xeonmc 1y agoIt's also the Swedish time format I believe[0] [0] https://stackoverflow.com/a/58633651 https://stackoverflow.com/a/58633651
- setopt 1y agoThat and the metric system is why en_SE is my preferred locale even though I’m not Swedish or in Sweden
- Kwpolska 1y agoWhich decimal separator does it use? Windows’ "English (Sweden)" locale uses commas.
- Symbiote 1y agoI'd assume comma, like en_DK. I'd like an en_EU definition to be added, except I went to find an official definition[1], and found the EU uses both. Elsewhere [2] it says the use of a comma is due to "technical limitations". I use en_GB or en_IE, but export TIME_STYLE=long-iso so I get ISO dates in many GNU programs like "ls". [1] https://style-guide.europa.eu/en/content/-/isg/topic?identifier=6.4-word-processor-punctuation-marks-spacing https://style-guide.europa.eu/en/content/-/isg/topic?identif... [2] https://commission.europa.eu/system/files/2023-11/styleguide_english_dgt_en.pdf https://commission.europa.eu/system/files/2023-11/styleguide... §6.10.
- progval 1y agoIt is not computer-friendly because the timezone is unspecified. And in some timezones, it is ambiguous during changes from DST to winter time.
- rocqua 1y agoLooking through the original article, this date format is only available in the RFC, and then only with the Z (which makes it UTC). Is there a timezoned version of this that is standardized?
- dijit 1y agothe number after the Z is the offset to UTC. 2025-09-07 10:57:00Z+2 would be CEST for example. (+2 hours ahead). 2025-09-07 04:57:00Z-4 would be EDT (4 hours behind UTC)
- isbvhodnvemrwvn 1y agoOffset is not the same as a timezone. Offsets change throughout the year in the same geographic areas (or don't or both do and don't)
- dijit 1y agoNo, timezones don’t change but they are swapped out by countries, offsets and timezones are an n:1 mapping. Multiple timezones represent the same offset, but those offsets are immutable. CEST will always be +2 UTC (unless something really changes politically). DST just marks that Sweden changes from CEST to CET from October to May. So Swedens offset changes, but the timezone does not change its offset.
- KronisLV 1y agoAt that point, just give me 2025-09-07T11:30:31.304[Europe/Riga] the machine can figure out the current offset and GMT itself because in any given time in the year I have no idea without looking it up.
- LukeShu 1y agoExcept for not including a timezone offset, that's one of the RFC 3339 formats.
- magnio 1y agoNot exactly computer friendly, since filenames cannot contain ":" on Windows.
- eadmund 1y agoNot all computers are Windows! And not all computer-users worry even a little bit about compatibility with Windows.
- theandrewbailey 1y agoConsidering that most normie non-tech people use Windows, compatibility with Windows is important.
- integralid 1y agoAnd cannot be longer than 8 characters on DOS.
- afiori 1y agoThen replace it with _ or anything else it is going to be equally understandable
- karambahh 1y agoOthers point out missing tz. It's also not that "user friendly": depending on their locale, users will usually expect for instance DD/MM/YYYY. Sorting by YYYY-MM-DD won't feel natural to them.
- reacweb 1y agoI am french. Everydays, we use DD/MM/YYYY or DD/MM/YY. Sometimes, I encounter YYYY-MM-DD, for example at the beginning of a document reference or in a file name. For me, it feels natural and I have no issue to make this switch mentally. The only problem I encounter is in english: MM/DD/YYYY. Hopefully less and less people are using this insane order.
- jolmg 1y ago> Sorting by YYYY-MM-DD won't feel natural to them. It's dictionary sorting.
- dvh 1y agoMine is YYYY-MM-DD--hh-mm-ss
- rdsubhas 1y agoIn most countries in the world, 24 hour time is just not human (user) friendly. Programmer-friendly for debugging? Sorry No. I don't mind the extra T in between and I'd actually like to see the timezone or zulu in logs when debugging. A counter view would be: it's half-human-half-computer inclined, but not objectively good for either.
- plusmax1 1y ago"most countries in the world" are perfectly fine with the 24 hour clock: https://en.wikipedia.org/wiki/Date_and_time_representation_by_country https://en.wikipedia.org/wiki/Date_and_time_representation_b... I fail to see why it is not considered human friendly. Its more specific, a day is 24 hours, at least I much prefer it to "am/pm".
- afiori 1y agoEspecially since there is very little logic to which 12 is midday and which is midnight does not have a clear logic
- afiori 1y agoThe extra T impacts legibility quite a lot and most systems that follow the standard either normalize everything to UTC or use a single global timezone to format everything
- jolmg 1y ago> "YYYY-MM-DD hh:mm:ss" > It is human-friendly and computer-friendly at the same time. It's not shell-friendly, because of the space. The shell being an interface between humans and the computer, this takes a chunk out of it being human-friendly and computer-friendly. You'll have to worry about quoting the thing, involve messing with IFS when making arrays of the things, extract both pieces out of text columns aligned with spaces, awk's NF wouldn't correspond with number of fields anymore, etc. Would make timestamps unnecessarily annoying to interact with. Better to at least make it an underscore. Still quite readable.
- burntsushi 1y agoIt's not elegant at all. This is a horrible idea because it doesn't account for time zone transitions. You could even end up with a time that will never appear on your clock. For example, what is the answer to in New York? SELECT DATETIME('2025-03-07 23:30:00', '+1 day', '+3 hours'); If you said `2025-03-09 02:30:00`, then that would just be wrong. Because that time never appeared on clocks in New York.
- anfogoat 1y ago> It is so elegant and common that even though it is not part of a standard ... YYYY-MM-DD hh:mm:ss seems valid ISO 8601 to me, isn't it? Neither the "T" nor the timezone are required as far as I recall. EDIT: The site says ISO 8601-1:2019 requires a T for datetimes, and that even though previous editions allowed for no T, a space was never allowed. This is shocking news to me.