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 from a vault export (should the vault truncate it?) As far as I know, there are no timezones with sub-second precision, but [[ https://docs.oracle.com/javase/8/docs/api/index.html?java/util/TimeZone.html | Java seems to represent them as millisecond integer ]] for some reason...

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?) 3. simply truncate 4. truncate and store seconds out of band (like the initial version of D6344 does) As far as I know, there are no timezones with sub-second precision, but [[ https://docs.oracle.com/javase/8/docs/api/index.html?java/util/TimeZone.html | Java seems to represent them as millisecond integer ]] for some reason...

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?) 3. simply truncate 4. truncate and store seconds out of band (like the initial version of D6344 does) As far as I know, there are no timezones with sub-second precision, but [[ https://docs.oracle.com/javase/8/docs/api/index.html?java/util/TimeZone.html | Java seems to represent them as millisecond integer ]] for some reason...