Hexadecimal clock counting down to 2038 problem

Re:Hexadecimal clock counting down to 2038 problem by doctor_eval on Sunday September 17, 2023 @08:42PM (#37550900)

Everyone - especially those in my own team - told me that dates needed to be human readable strings in my APIs and messages, but I ignored them and used Java time stamps (Unix, but milliseconds) instead.

Lo, nobody complained about the readability because most time problems are relative to other events, rather than to a specific clock time. 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. And using an integer obviates time zone and daylight savings corner cases. You can simply subtract two numbers and get useful information. And it’s much easier to do the math in your head and in scripts.

For those relatively rare times that you do need to know the clock time, there are CLI tools (ie, date -s) and websites galore.

Of course my use case was not everyone’s use case. But I ignored the blanket recommendation to use human readable time, and despite the naysayers, life became much easier for me and my team. I doubt that I would go back to string timestamps for any purpose.

Honestly, human time is for humans, it’s a presentation problem. Computer time is for computing.

[ Parent | on HN ]

Re:Hexadecimal clock counting down to 2038 problem by ogogmad on Sunday September 17, 2023 @11:40PM (#37551967)

Leap seconds and UTC vs UT1? Even in your use case, this would matter.

[ Parent | on HN ]

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 ]