4 ms·

> ((tm_year - 69) / 4) * 86400 Seems like there's another corner cut here, where the behavior of leap years at the end of a century (where they're skipped if a

> ((tm_year - 69) / 4) * 86400 Seems like there's another corner cut here, where the behavior of leap years at the end of a century (where they're skipped if a year is divisible by 100 unless it's divisible by 400) is not accounted for. I suppose using Unix time for dates in the far future isn't a good idea. I guess I'll file that away. (For the curious, the way this seems to work is that it's calibrated to start ticking up in 1973 and every 4 years thereafter. This is integer math, so fractional values are rounded off. 1972 was a leap year. From March 1st to December 31st 1972, the leap day was accounted for in `tm_yday`. Thereafter it was accounted for in this expression.)

growse 2y ago
> I suppose using Unix time for dates in the far future isn't a good idea. I guess I'll file that away. Not just Unix time, converting future local time to UTC and storing that is also fraught with risk, as there's no guarantee that the conversion you apply today will be the same as the one that needs to be applied in the future. Often (for future dates), the right thing to do is to store the thing you were provided (e.g. a local timestamp + the asserted local timezone) and then convert when you need to. (Past dates have fewer problems converting to UTC, because we don't tend to retroactively change the meaning of timezones).
jwilk 2y ago
> the behavior of leap years at the end of a century (where they're skipped if a year is divisible by 100 unless it's divisible by 400) is not accounted for. The article cites the original edition of POSIX from 1988. The bug in question was fixed in the 2001 edition: https://pubs.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap04.html#tag_04_14 https://pubs.opengroup.org/onlinepubs/007904975/basedefs/xbd...