Old timezones require second precision

[justin-schroeder]

In the ye olde days, timezones were not standardized so the offset from GMT is basically the geographic position of the timezone in degrees/minutes.

So the timezone offset for America/Detroit in 1904 is -05:32.18333333333334, or 5 hours, 32 minutes, 11 seconds. Since timezone offsets (+-00:00) cannot represent seconds 0.1.1 rounds these offsets to the nearest minute. -0532.

However, this causes problems when performing bi-directional format/parse — if you parse a date at midnight in one of these timezones and then format it back you will lose 11 seconds of time and the date will actually be the day before at 11:49pm.

To solve this, we need to add a second or even milliseconds to our timezone format. Perhaps something like +-HH:mm:ss.SSS with the ss.SSS being optional should be supported.

[SeanLuis]

@justin-schroeder The solution to the issue of bi-directional format/parse problems due to non-standardized historical timezone offsets has been addressed in commit 4e94ac.

In this commit, several modifications were made to support the inclusion of seconds and milliseconds in timezone offsets. This ensures that when parsing a date in one of these timezones and formatting it back, the precision of seconds and milliseconds is maintained, thus preventing any loss of time and ensuring the date remains accurate.

Key changes include:

1. Regex for ISO 8601 Compliance: Updated to handle milliseconds and seconds in timezone offsets.
2. Formatting and Parsing Functions: Enhanced to support the extended timezone format including seconds and milliseconds.
3. Utility Functions: Adjusted to work with the new extended formats.
4. Extended Types and Interfaces: Added support for the extended date and time format parts, including millisecond.

For a detailed view of these changes, you can refer to the specific commit in the repository: 4e94ac.

Please see the pull request comment here.