Re: Question about timezones in commit & tag dates

On 12/09/2021 16:07, Fabian Stelzer wrote:

On 12.09.21 16:21, Ævar Arnfjörð Bjarmason wrote:

quoted

On Sun, Sep 12 2021, Fabian Stelzer wrote:

quoted

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.

quoted

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