Specifying an offset, as certain datetime formats do, is worse than not specifying any timezone information at all. I'm not aware of a standardised computer date format that includes the symbolic timezone, sadly.

▲

zarzavat 3 days ago | parent [-]

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

	▲	lmm 3 days ago \| parent [-]
		What use case is there for preferring the offset (that wouldn't be better served by using instants)?