Re: Question about timezones in commit & tag dates

[Philip Oakley <philipoakley@iee.email>]

On 12/09/2021 16:07, Fabian Stelzer wrote:
> On 12.09.21 16:21, Ævar Arnfjörð Bjarmason wrote:
>> On Sun, Sep 12 2021, Fabian Stelzer wrote:
>>
>>> Hi,
>>> while working on correct key rollover and verifying signatures for past
>>> commits for the ssh signing topic i am trying to understand how Git
>>> deals with timestamps for commits & tags.
>>> For ssh signing the user will manage expiration times within their
>>> allowedSigners file. Those timestamps do not carry a timezone and i
>>> would assume a user (or automatic generation of this file) will assume
>>> the systems timezone for them.
>>> Therefore i wanted to pass the commit & tags timestamps adjusted to the
>>> system timezone to make sure key rollover will have no gaps or failed
>>> verification's especially when commit and system timezone differ greatly
>>> and might roll over to another day.
>>>
>>> However the commit & tags structs only seem to carry the objects
>>> timestamp as is, simply ignoring any timezone information. For the ssh
>>> feature i can easily enough parse the ident line again from the object
>>> header. But while looking at the usage of the existing date fields i can
>>> see that objects are sometimes sorted on and compared by these dates.
>>> When commands provide cut off times (--since) i think they might include
>>> or exclude commits erroneously when they were made in a different
>>> timezone around the cutoff date. ("log --since" indeed gives me some
>>> unexpected results when mixing multiple timezones. Based on some simple
>>> testing i think it just stops output when a commit falls outside of this
>>> window, even though there might be one before it wich is within)
>>>
>>> Is my understanding of this correct and this the expected behaviour?
>>> I think generally for git this does not matter much. But in certain
>>> situations this is problematic.
>>>
>>> I would have assumed that git would either add the timezone as well or
>>> adjust the commit timestamp upon populating the date field in the commit
>>> struct to UTC but i could not find anything like it.
>> Timezones are ultimately display information that's confusing to humans,
>> but not machines. Machines just need to deal with epochs, or when a
>> human supplies them a date convert a formatted date + timezone pair to
>> an epoch.
>>
>> So in the key expiry case, I'd expect that any such system would say
>> issue keys right now, now as in time(NULL), and we'd set those keys to
>> expire after some time, say 1 day, so time(NULL) + 60 * 60 * 24;
>>
>> If you're in UTC that might yield a very satisfying (to humans, a
>> machine won't care) expiry time. I.e. you'll get keys issued say at
>> midnight, and expiring midnight the following day.
>>
>> What you're saying sounds to me like you're conflating the two
>> things.
> You are correct. I somehow thought the stored timestamp would be in the
> specified timezone when it is not. The timezone is only used as
> reference for display.
>
>> Anyway, maybe I've misunderstood you. I just don't see how something
>> like key expiry would need to concern itself with anything but
>> epochs. If you conflate timezones with that and say "here's a key, it
>> expires at mindight" surely you'll have some keys last mere seconds,
>> others 10 hours etc.
>>
> The ssh allowedSigners file specifies key expiry in a "%Y%m%d%H%M%S"
> format without any timezone information. So i have to assume the systems
> timezone is used.
> But correcting my misconception of the stored commit timestamp i can
> simply present it in the systems timezone for ssh to compare it with the
> specified expiry date.
>
> Thanks for your help!
It is possible to have, near the international date line, places that
are more than 24 hours apart (local/calendar time), E.g compare Pago
Pago (-11) and Apia (+13).
In the wrong conditions, a 24hr expiry, using local/calendar time, could
have already expired at a near neighbour, because of the shift in their
local times. It ('date/time') is tricky confusing stuff without careful
consideration of the standards and terminology [1,2]. Regular folks can
easily be confused ;-) Sometimes things need spelling out rather more
than one may have expected/hoped.

[1] https://en.wikipedia.org/wiki/System_time and
[2] https://en.wikipedia.org/wiki/Unix_time
--
Philip