Hexadecimal clock counting down to 2038 problem

Re:Hexadecimal clock counting down to 2038 problem by paulddraper on Monday September 18, 2023 @05:36AM (#37554078)

> It’s so much easier to work out that two events occurred a few milliseconds apart when you don’t need to take segmentation (ie: ymdhms.s) into account.

IF you know they occurred a few milliseconds apart, integers are marginally easier.

  1695029423495
  1695029423502

  2023-09-18T09:30:23.495Z
  2023-09-18T09:30:24.502Z

But for every other case, it's much harder to discern the difference.

  1695029423495
  1695029483502

  2023-09-18T09:30:23.495Z
  2023-09-18T09:30:25.502Z

It's far easier to compare these using the commonly practice of ISO 8601.

[ Parent | on HN ]

Re:Hexadecimal clock counting down to 2038 problem by doctor_eval on Monday September 18, 2023 @06:14AM (#37554305)

that’s the argument I kept hearing, but in practice, it’s trivial.

    1695029423495
    1695029483502
    2023-09-18T09:30:23.495Z
    2023-09-18T09:30:25.502Z

In fact I can see by just looking at your integer timestamps that it’s about 60,000ms difference, or 60 seconds, so I think your time stamps are wrong.

I personally find that it's much more difficult to compute the number of seconds between those timestamps without help, and that’s my point.

[ Parent | on HN ]