The older RFC 2132 time offset option (tag 2) provides only a UTC offset in seconds, which is insufficient to determine DST transitions or derive human-readable abbreviations like "EST". Servers would have had to time lease expirations to DST boundaries, creating a self-inflicted stress test.

The TZ Database is preferred over POSIX strings because POSIX strings can accurately represent at most one DST transition rule, whereas the TZ Database provides backwards consistency and accuracy for nearly all real-world locations since 1970, including irregular rule changes.

TZ Name is preferred over POSIX string for most uses because it is easier for users to configure and provides historical accuracy. POSIX strings are more suitable for small-footprint applications that don't maintain a local copy of the TZ Database.

VTIMEZONE elements from iCalendar were considered but rejected because there is no global TZID registry, full entries require 300+ octets with no bound, and no operating system natively used VTIMEZONE at the time of writing.

The DHCPv6 encoding of the timezone options has exactly the same semantics and content as the DHCPv4 encoding, differing only in the option encoding format required by each protocol version.

The TZ Name option requires the client to already have a local copy of the TZ Database; configuration and distribution of the database is out of scope for this document. If the client lacks the database, the TZ Name option is not useful.

A client that supports the TZ Name option SHOULD prefer the TZ Name option over the POSIX string if it recognizes the returned TZ Name. If the client does not recognize the TZ Name, it MUST ignore this option.

As a matter of transition, clients that already use the deprecated time offset option MAY request both the time offset option and the new timezone option simultaneously.

Clients and servers implementing other timezone options MUST support the TZ POSIX String option (PCode/OPTION_NEW_POSIX_TIMEZONE) for basic compatibility.

Current implementations supporting the time offset IPv4 option (tag 2) SHOULD also implement the new timezone options. Other implementations SHOULD implement the new timezone options and SHOULD NOT implement the deprecated time offset IPv4 option.

Servers implementing either timezone option SHOULD implement the other one as well, so that clients need not request both options.

When a lease has expired and new timezone information is not forthcoming, the client MAY continue to use timezone information previously returned by the server, following the principle of least astonishment.

DHCPv4 option PCode (100) carries a POSIX 1003.1 timezone string. The format is a one-octet option code (100), a one-octet length N, followed by N octets of the IEEE 1003.1 TZ string, not null-terminated.

dns, registry

DHCPv4 option TCode (101) carries a TZ Database timezone name string. The format is a one-octet option code (101), a one-octet length N, followed by N octets of the TZ database name string, not null-terminated.

registry

The TZ Name is the name of a Zone entry in the TZ Database, corresponding to the name field of a zone line in the database's textual form. The string is not null-terminated. Example: Europe/Zurich.

The TZ POSIX String must conform to IEEE 1003.1 Section 8.3, except it MUST NOT begin with a colon (":"). The string is not null-terminated. Example: EST5EDT4,M3.2.0/02:00,M11.1.0/02:00.

IANA allocated DHCPv4 option codes PCode (100) and TCode (101), and DHCPv6 option codes OPTION_NEW_POSIX_TIMEZONE (41) and OPTION_NEW_TZDB_TIMEZONE (42) for the new timezone options defined in this document.

registry

IANA annotated the existing DHCPv4 time offset IPv4 option (tag 2) as deprecated, with a reference to this document (RFC 4833), which updates RFC 2132.

registry

An attacker supplying erroneous timezone information could cause clients to miss scheduled events, trigger cron jobs at wrong times, or repeat/skip jobs during DST transitions. Client operating systems may do well to confirm timezone changes with a human in critical environments.

security

Clients using the POSIX option should be suspicious of any UTC offset exceeding 25 hours (the POSIX limit); as of the RFC's writing the maximum real-world UTC offset is 14 hours.

security

Clients using the POSIX option should beware of timezone settings specifying unusual characters (e.g., control characters) in timezone abbreviations, as these may trigger security-relevant bugs in applications.

security

DHCPv6 OPTION_NEW_POSIX_TIMEZONE (option-code 41) encodes a TZ POSIX string. The 16-bit option-code field is 41, followed by a 16-bit option-length giving the number of octets, followed by the TZ POSIX string.

DHCPv6 OPTION_NEW_TZDB_TIMEZONE (option-code 42) encodes a TZ Database name. The 16-bit option-code field is 42, followed by a 16-bit option-length giving the number of octets, followed by the TZ Name string.