The road to Zettalinux [LWN.net]

The road to Zettalinux

Posted Sep 16, 2022 12:37 UTC (Fri) by epa (subscriber, #39769)
Parent article: The road to Zettalinux

If we move to 128-bit time_t then we can finally solve the year 292277026596 bug.

to post comments

The road to Zettalinux

Posted Sep 16, 2022 17:35 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (14 responses)

You're laughing, but my friend is working on a software that needs to deal with Excel spreadsheets. They actually had to switch from the native 64-bit datetime type in Go to their own type, because Go can't represent a range of more than about 500 years, and you do get spreadsheets with dates from outside of this range.

The reason for this is that Go uses nanoseconds since 1970 to represent the datetime. A 128-bit counter would have fixed this for good.

The road to Zettalinux

Posted Sep 16, 2022 17:50 UTC (Fri) by adobriyan (guest, #30858) [Link] (4 responses)

Jonathan Blow implemented 128-bit "Apollo Time" measured in femtoseconds since Moon landing.

Should be good enough for ZettaLinux.

The road to Zettalinux

Posted Sep 23, 2022 16:15 UTC (Fri) by schuyler_t (guest, #91921) [Link] (3 responses)

I'm gonna be that guy and point out that there's no way we know the exact time of the moon landing to the femtosecond, so I wonder how he picked what 0 is.

The road to Zettalinux

Posted Sep 23, 2022 18:26 UTC (Fri) by Wol (subscriber, #4433) [Link] (1 responses)

I'll be that other person to ask "how often do satellites need femto-leaps just to stay in sync?" Maybe they don't, but at that scale? Maybe they do, at which point the question "at what femtosecond did the moon landings happen?" no longer makes physical sense ...

Cheers,
Wol

The road to Zettalinux

Posted Oct 11, 2022 18:43 UTC (Tue) by reubenhwk (guest, #75803) [Link]

Why since the moon landing? Why not make 0 the femtosecond just before the big bang?

The road to Zettalinux

Posted Oct 11, 2022 19:12 UTC (Tue) by adobriyan (guest, #30858) [Link]

The streams are here:
https://www.youtube.com/watch?v=FjJDyIxIC5U
https://www.youtube.com/watch?v=qGW7sEgyfsw

IIRC, there was a small debate if start time or landing time should be used as epoch.

Due to general relativity all of this is probably moot.

The road to Zettalinux

Posted Sep 16, 2022 20:54 UTC (Fri) by riking (guest, #95706) [Link] (1 responses)

It's actually weirdly more complicated.

Go uses a 96-bit value for datetimes (64-bit seconds + 32-bit nanos), but a 64-bit nanoseconds value for durations (which is the 500 year range). The Duration between two representable Times is not always representable.

The road to Zettalinux

Posted Sep 19, 2022 0:52 UTC (Mon) by developer122 (guest, #152928) [Link]

that seems like a serious bug

The road to Zettalinux

Posted Sep 18, 2022 21:01 UTC (Sun) by k8to (guest, #15413) [Link] (4 responses)

I've had fun loading in ancient time and future times into software that is designed for time series data. I never really expected these things to be handled smoothly, but the bugs you get are sometimes fascinating. Sometimes they expose problems worth fixing.

There is definitely software that handles times after 2038 just fine. Some use a larger value, some decompose the time info into things that don't happen to overflow. What came as a surprise to me is just how many bugs you hit at 2100 and/or 2200, not because of the representation but because of all sorts of bad encoded assumptions in bits of logic here and there.

The road to Zettalinux

Posted Sep 18, 2022 21:47 UTC (Sun) by Wol (subscriber, #4433) [Link] (3 responses)

2038 is a Unix problem.

Y2K was a logic problem.

Pick had a "day 10,000" problem (counting from day 1 = 1 Jan 1968 iirc, can't remember the exact date). The number of programs that assumed (a) internal dates were at most 4 digits, and (b) day 9999 was so far into the future it would never arrive. Now we'll have a day 100,000 problem, but that'll be well after we're all gone :-)

At the end of the day, it's all down to people assuming, and not thinking it through. We had a big problem at work when a load of tools (our name for excel spreadsheets that report from Oracle or whatever) broke. TSS were upgrading all our laptops, the default date format somewhere changed, and all the SQL queries that returned dates changed the date format. So when you're using SUBSTRING to extract the bit of the date you want, and the format changes, everything breaks :-) I was *NOT* popular when I said "fix the tool, not the laptop". But they did it ... once I'd berated them that fixing the laptops was a stupid idea :-)

Cheers,
Wol

The road to Zettalinux

Posted Sep 19, 2022 8:38 UTC (Mon) by jem (subscriber, #24231) [Link] (2 responses)

>2038 is a Unix problem.

No, 2038 is a C Standard Library problem.

The road to Zettalinux

Posted Sep 19, 2022 12:35 UTC (Mon) by eru (subscriber, #2753) [Link] (1 responses)

The ANSI/ISO standard for C only says time_t is an arithmetic type capable of representing times. It says nothing about its size, or what the time zero is.
The convention of having time_t contain seconds since 1970 is from Unix.

The road to Zettalinux

Posted Sep 19, 2022 14:44 UTC (Mon) by jem (subscriber, #24231) [Link]

Well, does "Unix" say anything about the size of time_t? No, it's the implementation specific ABI which is largely defined by the hardware architecture. Of course C, the library, and time_t all originated from Unix.

My point was that the C standard library time functions are used outside of Unix: in a shipload of Windows software, and a megaton of embedded software that has traditionally been implemented i C and typically uses the C standard library that comes with the compiler.

OK, Unix defines time zero, but how many non-Unix systems using the libc API have defined it differently?

The road to Zettalinux

Posted Sep 23, 2022 17:26 UTC (Fri) by Uqbar (guest, #121169) [Link] (1 responses)

Condolences for your friend, even though i am not sure how to put "excel" aside of "software".

The road to Zettalinux

Posted Sep 23, 2022 18:37 UTC (Fri) by Wol (subscriber, #4433) [Link]

What's wrong with Excel? It's actually a VERY good spreadsheet. The problem comes with "when all you've got is a hammer, everything looks like a nail". Excel is NOT a database.

And my department at work, like in so many companies, relies on that database called Excel. It relies on that IDE called Excel. And Excel is pretty crap at those tasks, because those tasks are not what it was designed for, and those tasks are not what it is suitable for.

Cheers,
Wol