5 ms·
Dates are hard, it's got to be one of the things on the lists of "things programmers don't understand." Choices to represent dates as an integers (seconds from
by throwawayboise 5y ago
Dates are hard, it's got to be one of the things on the lists of "things programmers don't understand."
Choices to represent dates as an integers (seconds from an epoch), or as strings, or as arrays, or as other data types all come with a lot of non-obvious consequences and edge cases to deal with. I always use a provided "date" datatype from a library, and never try to roll my own with base data types if I have any choice in the matter. And they are still hard, depending on what range of dates you need to be able to handle.
- SamuelAdams 5y agoSemi-related, one of my favorite posts on UTC. Seems simple to use until it’s not. https://zachholman.com/talk/utc-is-enough-for-everyone-right https://zachholman.com/talk/utc-is-enough-for-everyone-right
- bfung 5y agoHeh, if dates are hard now, just wait till 2038 (https://en.m.wikipedia.org/wiki/Year_2038_problem https://en.m.wikipedia.org/wiki/Year_2038_problem)
- Corrado 5y agoYou know, when I started working with computers (many moons ago) and found out about the 2038 problem, I didn't worry about it. After all, that will never affect me, right? Well, it's 2022 and 2038 doesn't look that far away now. Hopefully I'll be retired by then and won't have to deal with it. But, something tells me that's not going to happen.
- pjmlp 5y agoThe issue is that even when retired, it might hit us in one form or the other.
- JdeBP 5y agoThe knowledge has indeed existed for years. * https://news.ycombinator.com/item?id=4128208 https://news.ycombinator.com/item?id=4128208