topic Re: POSIX time weirdness in API / CLI Discussion

POSIX time weirdness

Bob_Zimmerman — Thu, 05 Sep 2019 19:38:58 GMT

While looking at some objects in my R80.20 jumbo 33 SmartCenter, I noticed the "posix" values for creation and modification dates have too many digits. POSIX time is seconds since 1970-01-01T00:00:00Z, minus leap seconds. The largest value which can be represented with a 32-bit counter is 2,147,483,647, leading to the 2038 problem. I'm seeing values like 1,567,547,444,907.

The first ten digits match POSIX time for when I believe the object was last changed. Maybe the extras are for milliseconds? If so, calling it POSIX time is incorrect.

Can anybody explain what is going on?

Re: POSIX time weirdness

PhoneBoy — Fri, 06 Sep 2019 22:05:07 GMT

It's most definitely milliseconds.
From what I can tell, some implementations of POSIX time do seconds, others do milliseconds, and others still do microseconds.

Re: POSIX time weirdness

Bob_Zimmerman — Fri, 06 Sep 2019 23:20:46 GMT

Good to know. Definitely not POSIX-compliant time representation, though. As of IEEE Std 1003.1-2017, POSIX specified in sys/time.h that the timeval struct shall contain time_t (time in seconds) and suseconds_t (time since time_t in microseconds). It doesn't specify the time has to only be 32-bits, but it does separate the whole seconds from the fractional seconds.

The specification for the 'date' utility doesn't even include options for sub-second output.