3 ms·
This won't help you if you need to interface with existing files or protocols...
by 0x0 14y ago
This won't help you if you need to interface with existing files or protocols...
- Ovid 14y 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 14y 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 14y agoChange all unsigned ints that store time to signed. In another 68 years or so, change them all back to unsigned. :-)
- GhotiFish 14y 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 14y agoOops, got it backwards. Right now they are signed. Change them to unsigned. Then back and forth. Of course if you miss any...