Your 'epoch' idea is almost the correct approach. Imagine a C style packed bitfield structure similar to this: struct t_timebf { uint8 timesystem : 8;

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-timestamps-in-nanoseconds-c 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.