Clock fault clock fault
-
-
See that's funny.
-
This looks like a really old story. Why are you posting this? It's from like 50 years ago.
-
-
And it's the same time as the Unix epoch. What a coincidence!
Filed under: Increasing joke efficiency by taking all the fun out of it.
-
-
That's an oddly specific date
-
-
That's an oddly specific
-
It's the Unix (hence Linux) epoch time.
Which sucks, stupid open source. They should use the Windows epoch time instead, it's much better.
-
I wonder what kinds of faults they'll have come January 19, 2038 at 3:14am?
-
I wonder what kinds of faults they'll have come December 4, 292277026596 at 3:30pm?
-
That date is past the expected lifetime of the universe, right? This might be a half-
-
Which model of universal lifetime are you using?
Because 1010120 years is a long time. Although admittedly, nothing interesting is likely to happen after the first 101500 years or so...
Filed under: won't be able to render
<sup><sup>
adequately.
-
I was told that it is beyond the heat death of the universe.
-
I wonder what kinds of faults they'll have come January 19, 2038 at 3:14am?
Probably only really crufty old systems that have not yet upgraded their
time_t
. The main issue will probably be archived data.
-
In other news, setting an iP{hone,od,ad}'s date to Janurary 1st, 1970 bricks the device.
I have to ask why it's even possible to set the date that far back. Are they catering to time travelers?
-
In other news, setting an iP{hone,od,ad}'s date to Janurary 1st, 1970 bricks the device.
I thought it only bricked the device until time ticked over into positive territory? Which isn't a problem for people in Europe or Asia, but kind of annoying for people in the Americas…
-
I made an image for sharing:
-
I thought it only bricked the device until time ticked over into positive territory?
That I don't know. I didn't care much about the details quite frankly.
But if that's the case then it's good news for the people who bricked their devices.
-
I have to ask why it's even possible to set the date that far back. Are they catering to time travelers?
Yeah I honestly don't know why any devices or systems allow you to set the date to before they were manufactured or compiled. I guess there may be some good reason I just don't know of, or maybe they figure it isn't worth the extra effort to prevent it.
-
@Zecc said:
I have to ask why it's even possible to set the date that far back. Are they catering to time travelers?
Yeah I honestly don't know why any devices or systems allow you to set the date to before they were manufactured or compiled. I guess there may be some good reason I just don't know of, or maybe they figure it isn't worth the extra effort to prevent it.
Originally, the wallpaper images didn’t have a date-taken in their EXIF metadata. This meant that they were treated as taken on the file’s creation date, which is the date you installed the operating system. The problem is that if you upgrade your phone, then the wallpaper image timestamps will be sorted after the pictures you took with the old operating system and before the pictures you took with the new operating system.
This is rather unsightly, so Windows 10 added EXIF metadata to sort all of those images before any pictures you may have taken yourself with that phone. Any date prior to 2007 would probably have sufficed (assuming people don’t backdate pictures in their Camera Roll), but the developer who fixed the bug decided to be a bit clever: He chose April 4, 1975, the date of Microsoft’s founding.
-
Yeah I honestly don't know why any devices or systems allow you to set the date to before they were manufactured or compiled.
Lazy way to support for Islamic calendar? After all, the whole Europe might start using it soon.
-
Yeah I honestly don't know why any devices or systems allow you to set the date to before they were manufactured or compiled. I guess there may be some good reason I just don't know of, or maybe they figure it isn't worth the extra effort to prevent it.
I did a product where I set the default date in code to whenever it was that I wrote the RTC interface. That confused people, I don't know if they would have been less confused if it was 1970 but as the year was correct they said the clock was 'wrong' when installing it.
The manual did say you had to set the clock and tell it if you wanted daylight saving or not but apparently no-one ever reads the damn manual.For things with RTCs we now have the program/test stand initialise the RTC and set it to the correct date/time. That seems simpler.
Factory reset does take it back to a hardcoded date/time as we once had a bug where the RTC got scrambled and was sending gibberish back to the controller which promptly crashed (I didn't write that one and it should have had some checks). As the reset didn't clear the RTC that was bricked until a new firmware was installed
-
@PJH I'm not talking about files, I'm talking about devices and systems. It makes sense for files.
-
Question because I'm too lazy to google it.
A value returned by POSIX's time(), which is no. of seconds since epoch, includes UTC leap seconds?
-
A value returned by POSIX's time(), which is no. of seconds since epoch, includes UTC leap seconds?
No. UTC is civil time, which assumes that leap seconds don't exist. When a leap second happens, it's usual to either just correct the clock immediately (not normally a big problem) or push the adjustment through over a period of time (e.g., adjust by one millisecond per second over the following 1000 seconds). Either of these works well for most applications. The others typically need GPS time anyway, or are NTP implementations that are written by people who ought to know WTF they are doing…