1462

It's time to mentally prepare yourselves for this (lemmy.world)

submitted 7 months ago by The_Picard_Maneuver@lemmy.world to c/programmer_humor@programming.dev

256 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[-] Randelung@lemmy.world 87 points 7 months ago

We've gone too far. Everyone just switch to UTC please. Yes, it means some will go to bed at 2pm and get up at 10pm, so what.

[-] MystikIncarnate@lemmy.ca 13 points 7 months ago

I'm just saying, but we did.

Pretty much every electronic thing you own that resembles a computer (phones, tablets, laptops, desktops, even your damned TV) uses UTC. Every. Single. One. Translates that time to "local" whenever it needs to.

So when your TV goes from 9:32 to 9:33, is just showing the converted time from UTC each time.

Almost every device on the planet is keeping time in UTC.

Just because you don't see UTC time on your device, doesn't mean that's not what's happening. I had an issue where I needed to get into my computer's bios for something, as soon as the BIOS loaded and showed the time, it was "wrong" because it was in UTC. I'm sure plenty of newer BIOS dialogs are configured to account for timezones now, so yeah. I might be unique in this. It's still there.

[-] Cethin@lemmy.zip 7 points 7 months ago

Almost all computers count time as seconds from the epoch (midnight 1/1/1970). That then gets converted into a readable time, which may go through UTC to be converted first, but that's not how it's storing it.

[-] zarenki@lemmy.ml 2 points 7 months ago

Unix time is far less universal in computing than you might hope. A few exceptions I'm aware of:

Most real-time clock hardware stores datetime as separate binary-coded decimal fields representing months, days, hours, minutes, and seconds as one byte each, and often the year too (resulting in a year 2100 limit).
Python's datetime, WIN32's SYSTEMTIME, Java's LocalDateTime, and MySQL's DATETIME similarly have separate attributes for year, month, day, etc.
NTFS stores a 64-bit number representing time elapsed since the year 1601 in 100-nanosecond resolution for things like file creation time.
NTP uses an epoch of midnight 1900-01-01 with unsigned seconds elapsed and an unusual base-2 fractional part
GPS uses an epoch of midnight 1980-01-06 with a week number and time within the week as separate values.

Converting between time formats is a common source of bugs and each one will overflow in different ways. A time value might overflow in the year 2036, 2038, 2070, 2100, 2156, or 9999.

Also, Unix time is often managed with a separate nanoseconds component for increased resolution. Like in C struct timespec, modern *nix filesystems like ext4/xfs/btrfs/zfs, etc.