4 ms·
Actually, a friend of mine has written a fix for it (https://github.com/schwern/y2038 https://github.com/schwern/y2038) in C. Just use the new functions and you
by Ovid 13y ago
Actually, a friend of mine has written a fix for it (https://github.com/schwern/y2038 https://github.com/schwern/y2038) in C. Just use the new functions and you're probably good. It's under an MIT license, so have fun with it.
Me? I'm waiting for the idiots who claim it's a worldwide geek conspiracy à la Y2K. Here's a haiku (senryu) I wrote for that:
Is Y2K real?
The problem's being solved by
Men who can't find dates.
- 0x0 13y agoThis won't help you if you need to interface with existing files or protocols...
- Ovid 13y agoYes, that's a good point. At least it's a start (though I'm dubious about some assumptions the code makes regarding time zones).
- apaprocki 13y agoWell, tzdata zones usually either always have per-year entries (such as Morocco) or entries that describe "from now on". So the logic in the code would be valid for places like the US that very infrequently change DST rules -- it would only break if the US changed their DST rules after 2037. It appears anglocentric, though. If a user in Morocco used this on their system, it would undoubtedly lead to errors because Ramadan falls on different days every year and DST is not observed during Ramadan. Things would start to fail in subtle ways because DST might not be calculated correctly for a few days here or there every year depending on what timezone it is used with.
- btilly 13y agoChange all unsigned ints that store time to signed. In another 68 years or so, change them all back to unsigned. :-)
- GhotiFish 13y agoWhile I agree this works, It's also a bit unnerving to me that 68 years later we're still using a protocol that's using a representation of time that rolls over every 126 years.
- btilly 13y agoOops, got it backwards. Right now they are signed. Change them to unsigned. Then back and forth. Of course if you miss any...