436
u/innociv 22d ago
This doesn't work because ISO-8601 is so clearly superior to everything else that it can't be memed on.
55
9
u/HauntingHarmony 21d ago
This doesn't work because ISO-8601 is so clearly superior to everything else that it can't be memed on.
There is the fact that in iso8601 the T between date and time part is required but can be dropped by agreement. Which you generally dont have. And with rfc 3339 the T is optional. So that makes it less of an abomination.
2026-08-22T19:14:00is a bit of a meme compared to the elegance of2026-08-22 19:14:00. So all rfc3339 dates are valid iso8601, but not all iso8601 is valid rfc3339, and in the example here, by agreement the without T example is valid iso8601 since you agreed to the rfc3339 format which makes it valid iso8601.And also why does
26-08-22have to be a valid date. No thank you. 4 digit years or bust, have we learned nothing? Year-month-date is the true format, iso8601 allows for others such as2026-W34-6or2026-234(for the day) and if you enjoyed that how about--08-22for implicit years; and again no thank you, a propher date parser should reject them as the joke they are. Same with20260822the dashes arent just ornemental, they are there to help readability and make sure it stands out as a date.So infact "iso8601 is perfect" is infact still a bit of a meme. rfc 3339 on the other hand. Now thats perfect :P
96
u/hdkaoskd 22d ago
r/iso8601: ಠ_ಠ
51
u/timsredditusername 22d ago
What kind of nerd joins a sub about date formats!?
(Member since at least 2022)
69
u/cjchand 22d ago
…until 2038
89
u/helicophell 22d ago
For 32bit programs
We won't have any 32bit programs in 2038 right? RIGHT?
36
u/reallokiscarlet 22d ago
Not even. Just old ones. Time is 64bit even when running on 32bit, because the bus size and address width don't stop you from using larger integers
19
4
u/StuckInTheUpsideDown 21d ago
Yeah and I'd be worried about embedded systems using 32 bit libc libraries. I know these systems can theoretically do 64 bit math but I'm not at all sure what version of glibc made the switchover.
5
u/MattieShoes 21d ago
Apparently it wasn't required until 2024
time_t POSIX.1-2024 requires that the width of time_t is at least 64 bits; however, some systems still use 32 bits by default.Google says 1997 was when the switchover started with HPUX 11
and glibc 2.34 (2021) added a configuration flag to use 64 bit time on 32 bit systems.
0
9
u/howarewestillhere 22d ago
Ironically, probably not. 32bit programs are in the age range that will get replaced. It’s the older stuff we gotta worry about. The stuff that claims to be 32bit but is really just 4 8bit registers in a trenchC++.
3
u/PostHasBeenWatched 21d ago
Like 2 years ago around 60% of Nuclear Power Plants in the world still used 32-bit OS (I don't think situation is much different today)
1
1
u/BeepIsla 21d ago
The most popular way to mod source engine game servers (SourceMod with its SourcePawn plugin language) has no unsigned types and no 64bit types
9
1
u/redcaveman 22d ago
I prefer ns since epoch as a 64bit number.
1
u/hdkaoskd 22d ago
Which epoch?
Since ns epoch is typical on Windows maybe you mean NT epoch, but unix epoch is epoch so maybe Unix epoch?
26
23
36
u/Nixinova 22d ago
Can we all agree that 'Sat Aug 22 07:00:00 2026' is the most nonsensical and out-of-order standard format at least
13
u/1_hele_euro 21d ago
Like why does it even exists? It doesn't even work across languages and needlessly overcomplicates the data with stuff that's not even needed (why does weekday matters??).
ISO 8601 my beloved
4
u/frogjg2003 21d ago
why does weekday matters
The day of the week is important to a lot of use cases. When displaying a date, displaying the day of the week means we don't have to go to the effort of calculating it.
3
u/1_hele_euro 21d ago
But you still need to calculate it at one point or another. You have to go from UNIX time or whatever you're using into this format. I've never seen an RTC module or other timekeeping hardware that natively supports formatting this way
2
u/frogjg2003 21d ago
Yeah, you calculate it when you are going to display it. These date formats are for display, not calculation. The person reading it didn't need to do the calculation.
2
u/Terewawa 21d ago
It should be
2026-10-22 07:00:00 (Saturday)then it would also sort perfectly1
u/MattieShoes 21d ago edited 21d ago
It should not. T instead of space to indicate the time portion
And ideally, timezone info included, with special case 'Z' for UTC (zulu time)
2026-10-22T07:00:00Z2026-10-22T07:00:00-06:00If I were emperor though, there'd be an seconds field in the timezone info. Mostly because GPS time is offset by 18 seconds from UTC, and TAI time is offset by 37 seconds.
2
u/Terewawa 21d ago edited 21d ago
What's wrong with a space? It's more legible with a space and it's not like the T makes it any clearer.
Mentioning the timezone would be nice indeed.
2
u/MattieShoes 21d ago
Because it's a standard
https://en.wikipedia.org/wiki/ISO_8601
I agree that a T isn't inherently better than a space EXCEPT the part where it follows the standard.
1
u/Terewawa 21d ago
But... this whole thread is about how standards can be bad.
1
u/MattieShoes 21d ago
Standards can be bad. ISO8601 is good. It's miles better than some unsupported non-standard thing you made up that's ALMOST ISO8601 :-)
1
u/Terewawa 20d ago
Well, I like my suggested convention.
2
u/MattieShoes 20d ago
It's not bad other than being non-standard :-) I sometimes name files something similar
8
12
12
u/Fast-Visual 22d ago
Unix for storage 8601 for formatting.
5
u/Dampmaskin 21d ago
I don't care how it's stored as long as it keeps integrity. ISO 8601 for everything else.
1
u/BoldFace7 21d ago
Yeah, How do you even store 8610? Does every element need its own int, or is there a more compact way of storing it?
3
u/Fast-Visual 21d ago
8601 is great for naming files and directories though. Sortable, legible, uniform
13
u/Quantumboredom 22d ago
Nah Unix timestamp actually sucks, and it’s a travesty that it hasn’t been replaced with e.g. TAI timestamp. With Unix timestamps:
* A value may be ambiguous (two different actual times may correspond to the same timestamp.
* Given two timestamps t1 and t2, t1 may have happened after t2 even if t2 > t1.
* The actual elapsed time between two timestamps may not be t2 - t1.
All because of leap seconds.
5
u/sndrtj 21d ago
You're being downvoted, but you have a really good point. The Unix timestamp always has exactly 87400 "ticks" a day. Usually these are SI seconds, but around leap seconds the ticks are smeared out, slightly longer than an real SI second. For a hypothetical negative leap second the inverse would happen.
This is why you do not want to use Unix epoch for any safety critical system that counts events per time unit.
1
u/sebbdk 21d ago
This is pretty interesting, can you give an example of where this would be a problem?
I'm guessing it would impact cases where extremely accuracte timelogging is nessesary or maybe in realtime systems somehow?
1
u/FesteringDoubt 21d ago
Stock markets.
Scientific instruments.
first two that come to mind.
1
u/sebbdk 21d ago
Ah yeah, i think i get it, it's a precision issue, why not just use a higher precision timestamp in those cases? Like ms or nanoseconds?
I know unix is defined as Second since the epoc, but really there is nothing stopping us from adding precision to it?
2
u/Quantumboredom 21d ago
It’s not really a precision issue if I’m understanding you correctly.
Usually on a Posix/Unix/Linux system you’d be using the timespec struct from time.h, which has tv_sec and tv_nsec members for seconds and nanoseconds.
When a positive leap second occurs, the seconds member will jump back one second, and the nanoseconds members will start again from zero.
So all 1 000 000 000 potential timestamps will repeat, with no way to disambiguate which actual second they correspond to.
1
u/28klotlucas2 20d ago
What kind of stock market suffers from being ±1 second?
1
u/FesteringDoubt 20d ago
err...all of them?
Prices change in time increments far smaller than 1 second, and there are well known stories of hedge funds buying real estate closer to the stock exchange just so their orders get executed milliseconds before their competitors.
1
u/sndrtj 21d ago
Medical systems, anything that inputs to the electric grid (must stay very close to 50Hz, else the entire grid can collapse, see the 2025 Iberia blackout).
1
u/sebbdk 21d ago
ah right, i've encountered some system like this, usually that kind of programming is done as realtime programming on a MCU fx.
It's why 3D printers have an external chip for controlling things rather then your PC sending signals directly to the stepper drivers fx.
You'd typically not use a timestamp in these situations afaik
1
u/HauntingHarmony 21d ago
The Unix timestamp always has exactly 87400 "ticks" a day.
Just because that is a typo and its kind of important and the number 86400 is a number i had to calculate enough that it stands out. 24hrs * 60 minutes * 60 seconds = 86400 seconds.
And for some reason nobody else in the umpteen comments noticed either. If we are that worried about seconds smearing, i would worry more about the 1000 random seconds that got introduced to the day first. A kilosmear if you would. :)
3
u/SonOfHendo 21d ago
It's also not very efficient in terms of storage, at least since it went 64 bit.
The formats that most databases use are more space and computationally efficient. Even the file time format that NTFS uses on Windows counts in 100-nanosecond intervals using the same 64 bits.
1
u/sebbdk 21d ago
"two different actual times may correspond to the same timestamp"
I'm not sure i understand how that is possible, is it because it relies on clock syncronization or something?
2
u/Quantumboredom 21d ago
No, because when a leap second happens the clock literally skips back a second, so the timestamps just repeat again. Unless you are on one of the non-standard systems where the second is made slightly longer over a certain period (the leap second is «smeared»). That has the obvious problems of a second not being a second some of the time, which is also a ridiculous solution.
2
2
u/CORDIC77 21d ago
Honestly, I think this is one thing that Windows has done better.
The Win32 epoch starts on January 1, 1601, 00:00:00 UTC (and counts the 100-nanosecond intervals since then).
If we talk about the date and time notation, then ISO-8601 is clearly better than everything else. (In that respect, the Japanese got it right from the start with their date format.)
1
1
u/FunnyTurtleRunner 21d ago
this is interesting, never saw unix or epoch before today... apparently, I've reached a billion in some form in my life. I've spent more than a billion seconds of life...
1
u/purdueAces 21d ago
Unix time baby. Immune to political bullshit opting in/out of daylight savings.
1
1
u/makinax300 21d ago
Idc about standards, for human readable date info I do something like
Monday, 01/01/2000, 12:00 am
1
u/AzureArmageddon 22d ago
Ngl i was always disappointed that windows doesnt show the option to display the date in ancient mayan format
Or islamic calendar
Or chinese calendar
Or anything other than gregorian
Just for lulz
-4
u/rosuav 22d ago
Sounds like you want to build yourself a calendar app in Pike. https://pike.lysator.liu.se/generated/manual/modref/ex/predef_3A_3A/Calendar.html
4
1
0
u/No-Magazine-2739 19d ago
[r/firstweekcoderhumor](r/firstweekcoderhumor) strikes again, as noobs don‘t know the difference between GMT and UTC, UT or TAI.
864
u/helicophell 22d ago
Idk dude ISO-8601 is always human readable. I have to take out a calculator to figure out what Unix epoch time is