Re:Day.js Fast 2kB alternative to Moment.js with the same mo...
by extheat on Sunday October 09, 2022 @03:27AM
(#33138901)
I only see this being an issue storing times as strings. Why not store them as integers (like a Unix timestamp) or at least some standardized string format? The only reasonable use case I can think of where you absolutely need all this complexity is if you're rendering a calendar or something similar.
[ Parent
| on HN ]
Re:Day.js Fast 2kB alternative to Moment.js with the same mo...
by 9wzYQbTYsAIc on Sunday October 09, 2022 @03:45AM
(#33138958)
There are countless, profitable business use cases for accurate time tracking.
Re:Day.js Fast 2kB alternative to Moment.js with the same mo...
by ohbtvz on Sunday October 09, 2022 @08:41AM
(#33140463)
User: set an alarm in eight hours.
It's 10PM right now. At what time should the alarm be set? 6AM? Woops, tomorrow is the switch to DST! What now? User: remind me to brush my teeth on November 21st at 8AM.
Okay, will do! Wait, you took a plane on November 2nd and are now on the other side of the world? Should I remind you at 8AM or 5PM? User: please note my doctor's appointment next week at 10AM.
Sure thing bub! Wait, but you live in Morocco in 2019? And the government just announced that reverse DST will be in effect for the month of Ramadan?! WTF do I do now?---
tl;dr It's not just an issue of storage.
Re:Day.js Fast 2kB alternative to Moment.js with the same mo...
by jt2190 on Sunday October 09, 2022 @11:49AM
(#33142340)
> What now?
I mean, there is no way to write code to “handle” this that isn’t just guessing on the part of the programmer. The correct thing to do is to prompt the user for verification or further information.
> There are requirements that we, as humans, will intuitively find the right interpretation for…
Interpretation is subject to error. (Yes humans have immensely more context to work with than computer programs, but just because we we’re better guessers doesn’t mean we’re not still guessing.)