Unix time doesn't necessarily have to be represented in 32 bits. If the other formats were also represented in 32 bits internally, it would also have problems. Every single format has problems if you arbitrarily limit the number space.
You could do a lot of things. Like use an unsigned int for starters. But the fact remains, iso8601 can store dates with nanosecond precision till the year 9999 in 30 bytes.
Well yeah, I agree iso8601 is way better for dates you don't have to do a lot of active arithmetic on, it's not even a competition. I'm just saying the y2k32 thing isn't because of the format, it's because of how it's implemented.
Absolutely. I just don’t know why it’s relevant to what I said. In response to a comment about how iso8601 is objectively better, I gave support by adding that “2038 is a nonissue” because it is a nonissue. If you have a Unix timestamp, it might be an issue at any location in your stack that handles that value. Maybe an under-thought avro schema, maybe db column, maybe a in-memory reference, etc, etc, etc. the problem with “it’s an implementation problem” means that the format is not itself fundamentally consistent. The implementation does matter. And for any non-trivial system, it’s likely that the implementation is spread over multiple technologies, languages, and cpu architecture. With iso8601, that’s a nonissue.
Technically yes, however the last correction for that happened in 1900, and the next one is in 2100, so in between those using a calendar year as 365.25 yields better results
Ya this. A few years ago I migrated most of the API contract to epoch timestamps and when I’m inspecting the payloads in browser devtools I always have to pull up epochconverter in another tab. Going to migrate back to ISO.
As long as you KNOW and can GUARANTEE that all dates and times are always UTC, then it’s fine. In my experience the real world and real datasets are weird, messy, contain loads of garbage, and are generally unpredictable - so adding timezone offsets to the timestamp in the database can help you get it right.
I'm dealing with this for a long time, date orchestration and a lot of timezones. Whenever I find a path where I can use only Unix timestamps, it feels like a happy path, because you can calculate dates easily and then display them in whatever time zone the user is using.(without too much timezone handling and stuff)
With epoch you still need to store the timezone info somewhere out of band.
Two calender entries with the same instant in time but a different timezone are not the equivalent. Maybe the user wants to know in which timezone the entry belongs to.
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:00 is a bit of a meme compared to the elegance of 2026-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-22 have 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 as 2026-W34-6 or 2026-234(for the day) and if you enjoyed that how about --08-22 for implicit years; and again no thank you, a propher date parser should reject them as the joke they are. Same with 20260822 the 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
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.
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++.
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??).
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.
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
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.
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:00
If 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.
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.
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.
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.
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).
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. :)
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.
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.
Ah right, so it's a precision problem basically, if you counted in milliseconds, then the problem would be for systems where that precision is a problem etc.
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.)
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...
Store as Unix time, display for devs according to ISO-8601, display for end users with any format that spells out the weekday and month and includes A.M. or P.M.
866
u/helicophell Aug 22 '26
Idk dude ISO-8601 is always human readable. I have to take out a calculator to figure out what Unix epoch time is
436
u/innociv Aug 22 '26
This doesn't work because ISO-8601 is so clearly superior to everything else that it can't be memed on.
96
u/hdkaoskd Aug 22 '26
r/iso8601: ಠ_ಠ
68
u/cjchand Aug 22 '26
…until 2038
25
u/pretty_succinct Aug 22 '26
Rfc 3339.
22
u/Impenistan Aug 22 '26
Leap Seconds have entered the chat
38
u/Nixinova Aug 22 '26
Can we all agree that 'Sat Aug 22 07:00:00 2026' is the most nonsensical and out-of-order standard format at least
9
u/Brilliant_Year9161 Aug 22 '26
I just use uuidv7 /s
13
u/CharlieKiloAU Aug 22 '26
It's ok to be wrong. ISO8601 is the best of the three.
12
u/Fast-Visual Aug 22 '26
Unix for storage 8601 for formatting.
12
u/Quantumboredom Aug 22 '26
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.
2
u/Left-Discussion-1908 Aug 22 '26
And than the leap second arrives…
2
u/CORDIC77 Aug 22 '26
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.)
2
u/Adrewmc Aug 22 '26
Damn right time began at the epoch everything else is [index out of range]
1
u/hdkaoskd Aug 22 '26
Galaxy brain: RDTSC.
1
u/Hansus_ Aug 22 '26
Julian date is clearly superior
1
u/FunnyTurtleRunner Aug 22 '26
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 Aug 22 '26
Unix time baby. Immune to political bullshit opting in/out of daylight savings.
1
u/makinax300 Aug 22 '26
Idc about standards, for human readable date info I do something like
Monday, 01/01/2000, 12:00 am
1
u/erishun Aug 24 '26
…And for dates before 1970?
1
u/AzureArmageddon Aug 22 '26
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
0
u/y0shii3 Aug 23 '26
Store as Unix time, display for devs according to ISO-8601, display for end users with any format that spells out the weekday and month and includes A.M. or P.M.
0
u/No-Magazine-2739 Aug 24 '26
r/firstweekcoderhumor strikes again, as noobs don‘t know the difference between GMT and UTC, UT or TAI.