3 ms·
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 ti
by doctor_eval 3y ago
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.
- ogogmad 3y agoLeap seconds and UTC vs UT1? Even in your use case, this would matter. But yeah, I take your point.
- paulddraper 3y ago> 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.
- doctor_eval 3y agothat’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 two different ISO timestamps without help, and that’s my point.