Re: Question about timezones in commit & tag dates

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