Asia/Riyadh TZ abbreviation "+03"?
Wouldn’t this be better defined as "AST" for Arabia Standard Time per https://24timezones.com/Riyadh/time?
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.
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 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>.
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.
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> wrote:
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 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 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.
participants (5)
-
Arthur Olson -
Brian Inglis -
Guy Harris -
Paul Eggert -
Peter Chamberlin