| ▲ | zarzavat 3 days ago | |||||||
Agreed, offsets are an anti-pattern. Any time you have a nonzero offset you almost certainly want either a tz name (e.g. Europe/Paris), a local datetime, an instant, or a formatted string. Datetime + tz name: a point in time and space that is responsive to time zone changes. E.g. Our zoom meeting is on 3 Feb 2026 17:40 in Moscow time. Local date time: a calendar date that is independent of time zones. Instant: an exact point in time. e.g. the rocket will launch at 123456789 seconds from the Unix Epoch TAI. Formatted string: an exact point in time rendered for the human user in their local timezone and calendar, taking into account leap seconds. E.g. The rocket will launch on 7 Ramadan 1447 AH, Saudi time. | ||||||||
| ▲ | burntsushi 3 days ago | parent [-] | |||||||
> Datetime + tz name: a point in time and space that is responsive to time zone changes No. It isn't a point in time, because time zone transition rules can and do change. You need an offset as well. Then you can choose which thing you want to prioritize[1] when converting it to an instant in time. This is what RFC 9557 is for. [1]: https://docs.rs/jiff/latest/jiff/tz/enum.OffsetConflict.html | ||||||||
| ||||||||