Question about timezones in commit & tag dates

> 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.

> 
> 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.

> 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.
> 

> 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!