Okay, though for me the render of "[Date] [Time] +03 +03:00" just looked a bit odd. If there is no official abbreviation then perhaps remove the "+03"? On 23 Aug 2025 02:04, Paul Eggert wrote:

On 8/22/25 06:20, Peter Chamberlin via tz wrote:

...

Wouldn’t this be better defined as "AST" for Arabia Standard Time per https://24timezones.com/Riyadh/time?

No, as the source you cite got that from me and I made it up. Invented abbreviations (which can be a real problem) were removed in 2017.

On Aug 23, 2025, at 9:37 AM, Paul Eggert via tz <tz@iana.org> wrote:

On 2025-08-23 00:48, Peter Chamberlin wrote:

...

If there is no official abbreviation then perhaps remove the "+03"?

An abbreviation of some sort is required. For more on the constraints on abbreviations, please see <https://data.iana.org/time-zones/theory.html#abbreviations>.

In particular, "compatible with ... POSIX" refers to various mechanisms, dating back Bell Labs UNIX, that provide a time zone abbreviation given a time; POSIX specifies the tzname[] array. This means that, in order to support POSIX-compliant systems, the tz database must provide a time zone abbreviation string for all time values in all tz database timezones.

Maybe in SUS V6 POSIX.1/IEEE Std 1003.1-203X Issue 9, we could get them to drop "name" and add "UTC offset". ;^> Have any libraries, languages, utilities, or systems output a name for '%Z'? On 2025-08-23 11:40, Arthur Olson via tz wrote:

Not-so-fun fact: it took about two years of lobbying to get the standard changed from requiring a "time zone name" to requiring a "time zone name or abbreviation."

    @dashdashado

On Sat, Aug 23, 2025, 1:21 PM Guy Harris via tz <tz@iana.org <mailto:tz@iana.org>> wrote:

On Aug 23, 2025, at 9:37 AM, Paul Eggert via tz <tz@iana.org <mailto:tz@iana.org>> wrote:

> On 2025-08-23 00:48, Peter Chamberlin wrote: >> If there is no official abbreviation then perhaps remove the "+03"? > > An abbreviation of some sort is required. For more on the constraints on abbreviations, please see <https://data.iana.org/time-zones/ theory.html#abbreviations <https://data.iana.org/time-zones/ theory.html#abbreviations>>.

In particular, "compatible with ... POSIX" refers to various mechanisms, dating back Bell Labs UNIX, that provide a time zone abbreviation given a time; POSIX specifies the tzname[] array.

This means that, in order to support POSIX-compliant systems, the tz database must provide a time zone abbreviation string for all time values in all tz database timezones. I notice that only GNU date(1) appears to support %:/::/:::z zone formats: are there any plans to add it to gnulib, glibc, etc. strftime(3), and document it under the optional format prefix flags?

Could it also reuse perhaps '-' (shorter human readable formats like '%-N') as a synonym for ':::', and/or perhaps '+' (zero pad extended precision like '%+F') as a synonym for '::', given these all appear to be solely GNU date extensions so far? ‘%z’ Four-digit numeric time zone, e.g., ‘-0600’ or ‘+0530’, or ‘-0000’ if no time zone is determinable. This value reflects the numeric time zone appropriate for the current time, using the time zone rules specified by the ‘TZ’ environment variable. A time zone is not determinable if its numeric offset is zero and its abbreviation begins with ‘-’. The time (and optionally, the time zone rules) can be overridden by the ‘--date’ option. ‘%:z’ Numeric time zone with ‘:’, e.g., ‘-06:00’ or ‘+05:30’), or ‘-00:00’ if no time zone is determinable. This is a GNU extension. ‘%::z’ Numeric time zone to the nearest second with ‘:’ (e.g., ‘-06:00:00’ or ‘+05:30:00’), or ‘-00:00:00’ if no time zone is determinable. This is a GNU extension. ‘%:::z’ Numeric time zone with ‘:’ using the minimum necessary precision (e.g., ‘-06’, ‘+05:30’, or ‘-04:56:02’), or ‘-00’ if no time zone is determinable. This is a GNU extension. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retrancher but when there is no more to cut -- Antoine de Saint-Exupéry

On Aug 25, 2025, at 2:15 PM, Paul Eggert via tz <tz@iana.org> wrote:

On 2025-08-25 14:00, Brian Inglis via tz wrote:

...

I notice that only GNU date(1) appears to support %:/::/:::z zone formats: are there any plans to add it to gnulib, glibc, etc. strftime(3), and document it under the optional format prefix flags?

That has all been done as far as I know.

On what platforms have you seen "%:z", "%::z", and "%:::z" work in strftime()? I have not seen it on Ubuntu 24.04, FreeBSD 14, or macOS Sequoia; in all of them, those formats do not result in a time zone value, and the C compiler on Ubuntu even wants that invalid format specifications are being used.