1234567890 it is UNIX Time!

happygeek 0 312 Views

Did anyone else get just a wee zing of excitement at 11.30pm (GMT) last night? I will admit to raising my glass and downing a large Jim Beam Black in order to celebrate the fact that UNIX Time had hit 123 billion seconds. OK, so I am a geek, what can I say?

Other than, perhaps, I was most certainly not alone. Indeed, UNIX Epoch Time parties were springing up all over the planet, it would seem, in order to celebrate that milestone. What bloody milestone you might be wondering, and the answer is also a little geeky. You see Epoch Time started on January 1st 1971, at 00:00:00 of course.

Which means that at precisely 6:31:30 Eastern the UNIX Epoch time ticked over to 1234567890, which is enough to get any geek just a little excited.

Although not as excited as they might be come the year 2038 when 32-bit format UNIX Time will effectively expire courtesy of the UNIX Millennium Bug. Unless, of course, everyone gets updated to 64-bit systems before then in which case you will not have to worry about the end of Epoch Time as we know it for nearly 300 billion years or so.

I think that calls for another drink...

Dani AI

Generated

Nice bit of geekery — and a small correction worth noting. The Unix epoch actually begins at 00:00:00 UTC on 1 January 1970 (not 1971), so the numeric milestone you celebrated, 1234567890, corresponds to 2009-02-13 23:31:30 UTC (which was 18:31:30 Eastern). was onto a proper celebration even if the year slipped; Wired and the Unix time reference both record that moment. (en.wikipedia.org)

Good catch from about terminology — this is properly “Unix time” (sometimes called POSIX or epoch time), not a Linux-only thing. It’s a counting convention used across many OSes, file systems, languages and databases, so plenty of non-Linux systems share the same numbering scheme. (en.wikipedia.org)

The other big calendar headline is the Year 2038 problem: systems that store Unix time in a signed 32-bit integer will overflow at 03:14:07 UTC on 19 January 2038. That overflow makes the counter wrap to negative values and can break timestamps, filesystems, databases and long-lived devices that rely on 32-bit time fields. Many OS vendors and toolchains have been moving to 64-bit time_t, but not every device or build is safe yet. (en.wikipedia.org)

Quick practical check and mitigation notes. Create this tiny C program to see your C runtime’s time_t width:

#include <stdio.h>
#include <time.h>

int main(void) {
    printf("sizeof(time_t) = %zu\n", sizeof(time_t));
    return 0;
}

Compile and run with gcc -o check_time check_time.c && ./check_time. If it prints 8 you have a 64-bit time_t (good). If it prints 4 you’re on 32-bit time_t and should plan upgrades or rebuilds. On Linux, full 64-bit-time support in userland depends on recent glibc and kernel support (glibc 2.34 adds _TIME_BITS=64 support; kernel work around 5.x adds broader support), so check your distro/vendor notes and update embedded devices well before 2038. (lists.gnu.org)

Member Avatar for Andrieux
Andrieux 0 Junior Poster in Training

Fun...

Member Avatar for AceofSpades19
AceofSpades19 51 Junior Poster in Training

its unix time not linux time

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.

Edit Preview