Change Details

In a few days, timezones are going to be represented with a git-like `[+-]HHMM` (and they used to be an integer of minutes). I think it is an opportunity to add support for precision up to seconds, since we need this to properly support Bazaar: D6344#inline-50337 Proposed formats: 1. `[+-]HHMMSS`, which unfortunately is indistinguishable from garbage offsets we can find in ~2k git commits (though it's only a very small fraction of all commits 2. `[+-]HHMM.SS`, which may break git (or other implementations) when they try to read it

In a few days, timezones are going to be represented with a git-like `[+-]HHMM` (and they used to be an integer of minutes). I think it is an opportunity to add support for precision up to seconds, since we need this to properly support Bazaar: D6344#inline-50337 Proposed formats: 1. `[+-]HHMMSS`, which unfortunately is indistinguishable from garbage offsets we can find in ~2k git commits (though it's only a very small fraction of all commits) 2. `[+-]HHMM.SS`, which may break git (or other implementations) when they try to read it from a vault export (should the vault truncate it?)

In a few days, timezones are going to be represented with a git-like `[+-]HHMM` (and they used to be an integer of minutes). I think it is an opportunity to add support for precision up to seconds, since we need this to properly support Bazaar: D6344#inline-50337 Proposed formats: 1. `[+-]HHMMSS`, which unfortunately is indistinguishable from garbage offsets we can find in ~2k git commits (though it's only a very small fraction of all commits) 2. `[+-]HHMM.SS`, which may break git (or other implementations) when they try to read it from a vault export (should the vault truncate it?)