3 ms·

Yes, people should use a TAI-correlated time for timestamps and events corresponding to the present or past (the future is a different story). However, they sho

by Veserv 4y ago

Yes, people should use a TAI-correlated time for timestamps and events corresponding to the present or past (the future is a different story). However, they should not use TAI64 since, even though this is my first time seeing it, it is clearly a antiquated format. It is literally using a big-endian(!), 63-bit, unsigned (but biased) integer to encode time. Every single modern computer is little-endian by default and the usage of a 63-bit unsigned integer instead of a [64-bit unsigned integer] or [64-bit signed integer with reserved upper and lower values] is bizarre.

alphazard 4y ago
It's not helpful to criticize aspects of a system which have good reasoning behind them, without understanding and presenting that reasoning in good faith, and providing a better alternative. Endianness of formats is not a concern on modern CPUs since we have efficient mechanisms for adjusting endianness on load and store. The choice of biased 63 bit integer ensures the the same arithmetic can be performed using both a signed and unsigned 64 bit integer. The JVM comes to mind as a system without support for unsigned 64 bit integers (maybe they've fixed that by now). As mentioned the upper values are reserved for extensions, meaning the most significant bit could be set to switch to another interpretation, potentially when migrating to something more modern. So far it's unused, just evidence of good forward thinking protocol design. Additionally, big endianess allows the format to be sorted using string comparison.
- DiggyJohnson 4y ago
  Even if I agree with the thrust of your point, I think it’s too much to claim GP is not criticizing “in good faith” just because their critique wasn’t as defended as strongly as you’d prefer. Seems like a misuse of the term, unless you think GP had ulterior motives behind their critique of a datetime standard format.
butlerm 4y ago
Network formats (at least the popular ones) typically transmit in "network byte order", i.e most significant byte first. There are advantages in being able to read a hex dump without manually reversing the bytes in your head for every field that is two bytes or larger. Far from antiquated I would consider the selection of big-endian formats as an indication they actually gave some thought about what they were doing, ranking debugging convenience higher than a marginal efficiency gain on some cpus. The same consideration generally applies to all binary formats intended to be portable across systems.
patrec 4y ago
Ah hackernews -- where someone confidently decries a timestamp format designed by the world's most accomplished applied cryptographer as "bizarre" and "big-endian(!)". Did sorting ever occur to you?
- anonymoushn 4y ago
  Do the CPUs you use typically not have instructions for comparing little endian 64-bit integers?
  - messe 4y ago
    On embedded systems? No.
    - anonymoushn 4y ago
      Are they big endian or little endian? If they are little endian, is it cheaper to perform 8 1-byte compares, 4 2-byte compares, or 2 4-byte compares?
  - patrec 4y ago
    It can be convenient to be able to just sort as an opaque byte string.

by Veserv 4y ago

alphazard 4y ago

It's not helpful to criticize aspects of a system which have good reasoning behind them, without understanding and presenting that reasoning in good faith, and providing a better alternative. Endianness of formats is not a concern on modern CPUs since we have efficient mechanisms for adjusting endianness on load and store. The choice of biased 63 bit integer ensures the the same arithmetic can be performed using both a signed and unsigned 64 bit integer. The JVM comes to mind as a system without support for unsigned 64 bit integers (maybe they've fixed that by now). As mentioned the upper values are reserved for extensions, meaning the most significant bit could be set to switch to another interpretation, potentially when migrating to something more modern. So far it's unused, just evidence of good forward thinking protocol design. Additionally, big endianess allows the format to be sorted using string comparison.

DiggyJohnson 4y ago
Even if I agree with the thrust of your point, I think it’s too much to claim GP is not criticizing “in good faith” just because their critique wasn’t as defended as strongly as you’d prefer. Seems like a misuse of the term, unless you think GP had ulterior motives behind their critique of a datetime standard format.

butlerm 4y ago

Network formats (at least the popular ones) typically transmit in "network byte order", i.e most significant byte first. There are advantages in being able to read a hex dump without manually reversing the bytes in your head for every field that is two bytes or larger. Far from antiquated I would consider the selection of big-endian formats as an indication they actually gave some thought about what they were doing, ranking debugging convenience higher than a marginal efficiency gain on some cpus. The same consideration generally applies to all binary formats intended to be portable across systems.

patrec 4y ago

Ah hackernews -- where someone confidently decries a timestamp format designed by the world's most accomplished applied cryptographer as "bizarre" and "big-endian(!)". Did sorting ever occur to you?

anonymoushn 4y ago
Do the CPUs you use typically not have instructions for comparing little endian 64-bit integers?
- messe 4y ago
  On embedded systems? No.
  - anonymoushn 4y ago
    Are they big endian or little endian? If they are little endian, is it cheaper to perform 8 1-byte compares, 4 2-byte compares, or 2 4-byte compares?
- patrec 4y ago
  It can be convenient to be able to just sort as an opaque byte string.