I'm asking myself after having read on papers that around the year 2035, we, on the earth and our computers by the way, might have to correct our time by one second back to comply with astronomical time.
When I read that, I believed first that this would put computers in great trouble: A clock that is going back and replays a second that already existed wouldn't be supported by many programs, and first: operating systems.
But then I've figured that we are doing something similar every year: we are going back one hour when applying winter time. I don't know if it's the same in every country, but at 3 o'clock in the morning we decide that it's 2 o'clock.
How does a Linux operating system manage timestamped operations when this hour change happens and the timestamp goes from 2024-10-27 02:59:59.999999
to 2024-10-27 02:00:00.000000
? Every message ordered by time should be tricked then, for example.
But maybe this isn't what is happening, and going from 2024-10-27 02:59:59.999999
to 2024-10-27 02:00:00.000000
is still going, in terms of system timestamp, from 1730069999
to 1730070000
(+1) (in seconds)?
And in this case the problem of removing one second from our time, in 2035, would be different than going back one hour like we are doing each year? For example, that it could cause us to assign:
2019682799 = 2034-12-31 23:59.59
,
2019682800 = 2035-01-01 00:00.00
,
2019682801 = 2035-01-01 00:00.00
2019682802 = 2035-01-01 00:00.01
But the problem here is that:
Computers with corrected OS will meet computers without correction (too old or not updated OS), believing that:
2019682801 = 2035-01-01 00:00.01
and2019682802 = 2035-01-01 00:00.02
when it's not the case. But this is the same problem if some OS still exist that don't know about summer and winter time changes.I guess that there aren't many examples of code like this around the world:
timestamp = System.timeInMillis() millis = millis % 1000 secondsSince1970 = millis / 1000 seconds = secondsSince1970 % 60 minutesSince1970 = ...
because here, the
seconds
variable becomes wrong in 2035 if the second removal is applied, as2019682802
should lead to01
and not to02
.