Hacker News Reader

Comment by vmception | Hacker News Reader

Cant this just be Epoch 0 and the next one be Epoch 1 and so on?

Adding a designation before the number, or date parsers knowing to separate the first or last digit from the rest of the number, meaning that its not just an overflowing large number its two numbers

Any undesignated timestamp being part of epoch 0

View on HN

You might as well just use a 64 bit int if you're going to be changing code anyways

But this blog post is about how code which is already using 64 bit ints can have code which silently truncates. Another case of C's loose handling of types, whereas in Rust there would've been an explicit cast required (granted, in this case the macro expands to having explicit type casts)

> You might as well just use a 64 bit int if you're going to be changing code anyways

That’s such a waste though. We could the current Unix time as is, and use a single additional bit to indicate if it’s the original epoch, or the new one. Imagine the net savings worldwide by using only 33 bits rather than 64 for the next 68 years.

What net savings? Dates will still get padded out to a byte alignment when in memory and being processed on the CPU (or gods help us all). You'd just be making it so there's extra handling any time you serialized it across I/O, to save a few bytes there. If you really wanted to save those bytes you can write your own serialization format, and that might make sense if you're sending massive amounts of timestamps or similar (but you'd probably see better results by compressing it first), but don't try and rope the rest of us into that pain when we aren't, like, serializing logs or something.

That's a good solution for future code, but not for past code. For example, lots of past code makes the assumption that

    current_unix_time+1 second > current_unix_time

which won't be true when the wraparound happens.

This is also a good case for why unsigned integers are useful. Time calculations using delta values are insensitive to a single wraparound event.

This is a common thing in embedded where 1ms ticks mean overflows every few weeks. Makes me wonder if a more resilient system would have such frequent overflows to force people to come to grips with them.

That's the big problem with leap seconds IME. Every time one happens we find that the fixes for the bugs that happened last time have been undone during the intervening period.

Also to be found out there, and which would need attention, is use of 0 as a sentinel

    if time = 0
      // handle missing data case
    else
      ...

The kind of thing that makes you wonder "what sort of a day was 1 Jan 1970, actually?"

Developers in the UK are used to UTC being the same as the UK's winter timezone, and so it's a bit confusing that time 0 is not midnight but 1AM on 1 Jan 1970, due to the short-lived British Standard Time.

Do you have a link about British Standard Time? I can't really find anything about it online.

Shouldn't tzdata contain historical offsets, too?

Maybe. But doesn't have any historic context.

Well, that's just the payback for making NULL interchangeable with 0. Where map data is concerned, there's always a bunch of random objects reported to be floating in the Gulf of Guinea. (Specifically, at [0,0])

Your 'epoch' idea is almost the correct approach.

Imagine a C style packed bitfield structure similar to this:

  struct t_timebf {
    uint8 timesystem : 8;
    sint64 timedata : 56;
  }

For clarity, 'unsigned' and 'signed' int types with minimum bit sizes are defined either by macros or a header, and only 'signed' types are sign bit extended on read.

Up to 255 standards may be defined which will define at least: an epoch for that standard, how the 56 bits for the timedata field are used to store data.

Standard 255 should be reserved as invalid (a guard against timestamp manipulation error).

Standards 254 down through 248 should be reserved in case there is a need for a program specific format that should not be handled by a standard library. The seven slots are reserved to allow up to that many revisions / variations of new timestamp types without further complicating the software.

Standard 0 might be reserved or assigned to Unix epoch timestamps. (see also 255 for folding naive manipulations back to a 56 bit timestamp.)

Standard 1 might be 56-bit microseconds (0.001 seconds), with a Unix epoch?

Standard 2 might be 56-bit milliseconds (0.000001 seconds), with a Unix epoch?

Standard 3 might be 56-bit nanoseconds (0.000000001 seconds), with a Unix epoch?

Those are (approximately) the current popular ranges of timestamps, and the reason for supporting 1e+0, 1e-3, 13-6, and 1e-9 are the approximately 30, 20, 10, and 0 extra bits of offered precision over the other timestamps.

When writing that out however, I realized that even at a full 64 bits, a nanosecond precision timestamp has a woefully inadequate number of bits. (only ~524 years of precision according to someone that did the math ( https://stackoverflow.com/questions/43451565/store-timestamp... ))

If storage isn't a concern, it might be better to utilize 128 or more bits for a timestamp to ensure there's sufficient room for the desired range. However at that point it makes much more sense for application specific choices.

A timestamp in many applications should probably include a reference timezone anyway.

Or just use a double at that point?

A double would be even worse. That would consolidate an insane level of accuracy near whatever the epoch for the system was, and have equally insanely large leaps the further away from the epoch someone is.

In modern systems "a double-precision (64-bit) binary floating-point number has a coefficient of 53 bits (including 1 implied bit), an exponent of 11 bits, and 1 sign bit. " (Wikipedia since I had to look up the exact details).

This has been done, and it creates fragmented behavior across systems.

Apple has their version. https://developer.apple.com/documentation/corefoundation/154...

Not really related other than being a different mess, but I've been running with DNSSEC enabled for a few months and it seems developer.apple.com is one of the few that fail DNSSEC validation (due to two different issues :/) and has been for a while (maybe always):

https://dnsviz.net/d/developer.apple.com/dnssec/

My favorite DNSSEC issue is that Verisign's DNSSEC checker fails DNSSEC:

https://dnsviz.net/d/dnssec-analyzer.verisignlabs.com/dnssec...

At least there is an easy solution to this mess, just remove it entirely. It is obvious that almost no one uses it.

Reply on news.ycombinator.com