2 ms·
Good point, as it pertains to local time. You can authoritatively say the answer for UTC though.
by haberman 13y ago
Good point, as it pertains to local time. You can authoritatively say the answer for UTC though.
- CanSpice 13y agoNo you can't, because leap seconds affect UTC as well. We don't know how many leap seconds are going to be added or subtracted between now and then.
- haberman 13y agoIt does not matter, because leap seconds do not affect the UNIX timestamp <-> UTC mapping. That is the whole point of what I am saying. The UNIX timestamp for 2023-01-01 00:00 UTC is 1672560000. I can tell you that right now even though I do not know how many leap seconds will be added between now and then.
- CanSpice 13y agoHuh. I didn't know that the UNIX timestamp essentially gets recalculated at UTC midnight every day to ensure that midnight now = midnight yesterday + 86400. I take back my previous argument.
- magila 13y agoBut what does that really buy you? We already have to store such dates using a datetime struct to handle the common case where the user wants to deal in local time. In what context could you not handle UTC the same way as local time?