{"thread":{"id":"56489","subject":"Question about timezones in commit & tag dates","startedAt":"2021-09-12T11:35:47Z","lastAt":"2021-09-12T16:16:09Z","messageCount":4,"participants":["Fabian Stelzer","Ævar Arnfjörð Bjarmason","Philip Oakley"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"435629","messageId":"b39aab0a-bf53-9e33-59a7-d4f1a06e72a7@gigacodes.de","threadId":"56489","inReplyTo":null,"subject":"Question about timezones in commit & tag dates","fromName":"Fabian Stelzer","fromEmail":"fs@gigacodes.de","sentAt":"2021-09-12T11:35:41Z","receivedAt":"2021-09-12T11:35:47Z","isPatch":false,"sender":{"key":"fs@gigacodes.de","avatar":"https://avatars.githubusercontent.com/u/564858?v=4"},"body":"Hi,\nwhile working on correct key rollover and verifying signatures for past\ncommits for the ssh signing topic i am trying to understand how Git\ndeals with timestamps for commits & tags.\nFor ssh signing the user will manage expiration times within their\nallowedSigners file. Those timestamps do not carry a timezone and i\nwould assume a user (or automatic generation of this file) will assume\nthe systems timezone for them.\nTherefore i wanted to pass the commit & tags timestamps adjusted to the\nsystem timezone to make sure key rollover will have no gaps or failed\nverification's especially when commit and system timezone differ greatly\nand might roll over to another day.\n\nHowever the commit & tags structs only seem to carry the objects\ntimestamp as is, simply ignoring any timezone information. For the ssh\nfeature i can easily enough parse the ident line again from the object\nheader. But while looking at the usage of the existing date fields i can\nsee that objects are sometimes sorted on and compared by these dates.\nWhen commands provide cut off times (--since) i think they might include\nor exclude commits erroneously when they were made in a different\ntimezone around the cutoff date. (\"log --since\" indeed gives me some\nunexpected results when mixing multiple timezones. Based on some simple\ntesting i think it just stops output when a commit falls outside of this\nwindow, even though there might be one before it wich is within)\n\nIs my understanding of this correct and this the expected behaviour?\nI think generally for git this does not matter much. But in certain\nsituations this is problematic.\n\nI would have assumed that git would either add the timezone as well or\nadjust the commit timestamp upon populating the date field in the commit\nstruct to UTC but i could not find anything like it.\n\nBest regards,\nFabian\n"},{"id":"435646","messageId":"87fsu997wn.fsf@evledraar.gmail.com","threadId":"56489","inReplyTo":"b39aab0a-bf53-9e33-59a7-d4f1a06e72a7@gigacodes.de","subject":"Re: Question about timezones in commit & tag dates","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-09-12T14:21:18Z","receivedAt":"2021-09-12T14:40:55Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Sun, Sep 12 2021, Fabian Stelzer wrote:\n\n> Hi,\n> while working on correct key rollover and verifying signatures for past\n> commits for the ssh signing topic i am trying to understand how Git\n> deals with timestamps for commits & tags.\n> For ssh signing the user will manage expiration times within their\n> allowedSigners file. Those timestamps do not carry a timezone and i\n> would assume a user (or automatic generation of this file) will assume\n> the systems timezone for them.\n> Therefore i wanted to pass the commit & tags timestamps adjusted to the\n> system timezone to make sure key rollover will have no gaps or failed\n> verification's especially when commit and system timezone differ greatly\n> and might roll over to another day.\n>\n> However the commit & tags structs only seem to carry the objects\n> timestamp as is, simply ignoring any timezone information. For the ssh\n> feature i can easily enough parse the ident line again from the object\n> header. But while looking at the usage of the existing date fields i can\n> see that objects are sometimes sorted on and compared by these dates.\n> When commands provide cut off times (--since) i think they might include\n> or exclude commits erroneously when they were made in a different\n> timezone around the cutoff date. (\"log --since\" indeed gives me some\n> unexpected results when mixing multiple timezones. Based on some simple\n> testing i think it just stops output when a commit falls outside of this\n> window, even though there might be one before it wich is within)\n>\n> Is my understanding of this correct and this the expected behaviour?\n> I think generally for git this does not matter much. But in certain\n> situations this is problematic.\n>\n> I would have assumed that git would either add the timezone as well or\n> adjust the commit timestamp upon populating the date field in the commit\n> struct to UTC but i could not find anything like it.\n\nTimezones are ultimately display information that's confusing to humans,\nbut not machines. Machines just need to deal with epochs, or when a\nhuman supplies them a date convert a formatted date + timezone pair to\nan epoch.\n\nSo in the key expiry case, I'd expect that any such system would say\nissue keys right now, now as in time(NULL), and we'd set those keys to\nexpire after some time, say 1 day, so time(NULL) + 60 * 60 * 24;\n\nIf you're in UTC that might yield a very satisfying (to humans, a\nmachine won't care) expiry time. I.e. you'll get keys issued say at\nmidnight, and expiring midnight the following day.\n\nWhat you're saying sounds to me like you're conflating the two\nthings. So as an example, any bugs in the --since logic aside, surely\nthe sane workings of such a feature is to take a formatted date +\ntimezone pair in the user's *local* timezone, convert it to an epoch,\nand then filter on that.\n\nThat's going to give output that's confusing to some humans, but is\ncorrect. E.g. if I want all commits since 00:00 on Monday I might be\nsurprised to see commits from Sunday afternoon, that's going to be\nbecause we took my idea of 00:00 on Monday, converted it to an epoch,\nand then used that as a filter.\n\nAnyway, maybe I've misunderstood you. I just don't see how something\nlike key expiry would need to concern itself with anything but\nepochs. If you conflate timezones with that and say \"here's a key, it\nexpires at mindight\" surely you'll have some keys last mere seconds,\nothers 10 hours etc.\n"},{"id":"435647","messageId":"b121acdf-354f-c896-d2f6-b221ea2443c1@gigacodes.de","threadId":"56489","inReplyTo":"87fsu997wn.fsf@evledraar.gmail.com","subject":"Re: Question about timezones in commit & tag dates","fromName":"Fabian Stelzer","fromEmail":"fs@gigacodes.de","sentAt":"2021-09-12T15:07:22Z","receivedAt":"2021-09-12T15:07:31Z","isPatch":false,"sender":{"key":"fs@gigacodes.de","avatar":"https://avatars.githubusercontent.com/u/564858?v=4"},"body":"On 12.09.21 16:21, Ævar Arnfjörð Bjarmason wrote:\n> \n> On Sun, Sep 12 2021, Fabian Stelzer wrote:\n> \n>> Hi,\n>> while working on correct key rollover and verifying signatures for past\n>> commits for the ssh signing topic i am trying to understand how Git\n>> deals with timestamps for commits & tags.\n>> For ssh signing the user will manage expiration times within their\n>> allowedSigners file. Those timestamps do not carry a timezone and i\n>> would assume a user (or automatic generation of this file) will assume\n>> the systems timezone for them.\n>> Therefore i wanted to pass the commit & tags timestamps adjusted to the\n>> system timezone to make sure key rollover will have no gaps or failed\n>> verification's especially when commit and system timezone differ greatly\n>> and might roll over to another day.\n>>\n>> However the commit & tags structs only seem to carry the objects\n>> timestamp as is, simply ignoring any timezone information. For the ssh\n>> feature i can easily enough parse the ident line again from the object\n>> header. But while looking at the usage of the existing date fields i can\n>> see that objects are sometimes sorted on and compared by these dates.\n>> When commands provide cut off times (--since) i think they might include\n>> or exclude commits erroneously when they were made in a different\n>> timezone around the cutoff date. (\"log --since\" indeed gives me some\n>> unexpected results when mixing multiple timezones. Based on some simple\n>> testing i think it just stops output when a commit falls outside of this\n>> window, even though there might be one before it wich is within)\n>>\n>> Is my understanding of this correct and this the expected behaviour?\n>> I think generally for git this does not matter much. But in certain\n>> situations this is problematic.\n>>\n>> I would have assumed that git would either add the timezone as well or\n>> adjust the commit timestamp upon populating the date field in the commit\n>> struct to UTC but i could not find anything like it.\n> \n> Timezones are ultimately display information that's confusing to humans,\n> but not machines. Machines just need to deal with epochs, or when a\n> human supplies them a date convert a formatted date + timezone pair to\n> an epoch.\n> \n> So in the key expiry case, I'd expect that any such system would say\n> issue keys right now, now as in time(NULL), and we'd set those keys to\n> expire after some time, say 1 day, so time(NULL) + 60 * 60 * 24;\n> \n> If you're in UTC that might yield a very satisfying (to humans, a\n> machine won't care) expiry time. I.e. you'll get keys issued say at\n> midnight, and expiring midnight the following day.\n> \n> What you're saying sounds to me like you're conflating the two\n> things.\n\nYou are correct. I somehow thought the stored timestamp would be in the\nspecified timezone when it is not. The timezone is only used as\nreference for display.\n\n> Anyway, maybe I've misunderstood you. I just don't see how something\n> like key expiry would need to concern itself with anything but\n> epochs. If you conflate timezones with that and say \"here's a key, it\n> expires at mindight\" surely you'll have some keys last mere seconds,\n> others 10 hours etc.\n> \n\nThe ssh allowedSigners file specifies key expiry in a \"%Y%m%d%H%M%S\"\nformat without any timezone information. So i have to assume the systems\ntimezone is used.\nBut correcting my misconception of the stored commit timestamp i can\nsimply present it in the systems timezone for ssh to compare it with the\nspecified expiry date.\n\nThanks for your help!\n"},{"id":"435649","messageId":"1002242a-a353-a904-5c1a-f23b0c5ed1a3@iee.email","threadId":"56489","inReplyTo":"b121acdf-354f-c896-d2f6-b221ea2443c1@gigacodes.de","subject":"Re: Question about timezones in commit & tag dates","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-09-12T16:16:04Z","receivedAt":"2021-09-12T16:16:09Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 12/09/2021 16:07, Fabian Stelzer wrote:\n> On 12.09.21 16:21, Ævar Arnfjörð Bjarmason wrote:\n>> On Sun, Sep 12 2021, Fabian Stelzer wrote:\n>>\n>>> Hi,\n>>> while working on correct key rollover and verifying signatures for past\n>>> commits for the ssh signing topic i am trying to understand how Git\n>>> deals with timestamps for commits & tags.\n>>> For ssh signing the user will manage expiration times within their\n>>> allowedSigners file. Those timestamps do not carry a timezone and i\n>>> would assume a user (or automatic generation of this file) will assume\n>>> the systems timezone for them.\n>>> Therefore i wanted to pass the commit & tags timestamps adjusted to the\n>>> system timezone to make sure key rollover will have no gaps or failed\n>>> verification's especially when commit and system timezone differ greatly\n>>> and might roll over to another day.\n>>>\n>>> However the commit & tags structs only seem to carry the objects\n>>> timestamp as is, simply ignoring any timezone information. For the ssh\n>>> feature i can easily enough parse the ident line again from the object\n>>> header. But while looking at the usage of the existing date fields i can\n>>> see that objects are sometimes sorted on and compared by these dates.\n>>> When commands provide cut off times (--since) i think they might include\n>>> or exclude commits erroneously when they were made in a different\n>>> timezone around the cutoff date. (\"log --since\" indeed gives me some\n>>> unexpected results when mixing multiple timezones. Based on some simple\n>>> testing i think it just stops output when a commit falls outside of this\n>>> window, even though there might be one before it wich is within)\n>>>\n>>> Is my understanding of this correct and this the expected behaviour?\n>>> I think generally for git this does not matter much. But in certain\n>>> situations this is problematic.\n>>>\n>>> I would have assumed that git would either add the timezone as well or\n>>> adjust the commit timestamp upon populating the date field in the commit\n>>> struct to UTC but i could not find anything like it.\n>> Timezones are ultimately display information that's confusing to humans,\n>> but not machines. Machines just need to deal with epochs, or when a\n>> human supplies them a date convert a formatted date + timezone pair to\n>> an epoch.\n>>\n>> So in the key expiry case, I'd expect that any such system would say\n>> issue keys right now, now as in time(NULL), and we'd set those keys to\n>> expire after some time, say 1 day, so time(NULL) + 60 * 60 * 24;\n>>\n>> If you're in UTC that might yield a very satisfying (to humans, a\n>> machine won't care) expiry time. I.e. you'll get keys issued say at\n>> midnight, and expiring midnight the following day.\n>>\n>> What you're saying sounds to me like you're conflating the two\n>> things.\n> You are correct. I somehow thought the stored timestamp would be in the\n> specified timezone when it is not. The timezone is only used as\n> reference for display.\n>\n>> Anyway, maybe I've misunderstood you. I just don't see how something\n>> like key expiry would need to concern itself with anything but\n>> epochs. If you conflate timezones with that and say \"here's a key, it\n>> expires at mindight\" surely you'll have some keys last mere seconds,\n>> others 10 hours etc.\n>>\n> The ssh allowedSigners file specifies key expiry in a \"%Y%m%d%H%M%S\"\n> format without any timezone information. So i have to assume the systems\n> timezone is used.\n> But correcting my misconception of the stored commit timestamp i can\n> simply present it in the systems timezone for ssh to compare it with the\n> specified expiry date.\n>\n> Thanks for your help!\nIt is possible to have, near the international date line, places that\nare more than 24 hours apart (local/calendar time), E.g compare Pago\nPago (-11) and Apia (+13).\nIn the wrong conditions, a 24hr expiry, using local/calendar time, could\nhave already expired at a near neighbour, because of the shift in their\nlocal times. It ('date/time') is tricky confusing stuff without careful\nconsideration of the standards and terminology [1,2]. Regular folks can\neasily be confused ;-) Sometimes things need spelling out rather more\nthan one may have expected/hoped.\n\n[1] https://en.wikipedia.org/wiki/System_time and\n[2] https://en.wikipedia.org/wiki/Unix_time\n--\nPhilip\n"}]}