Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0000772 [1003.1(2013)/Issue7+TC1] System Interfaces Editorial Enhancement Request 2013-10-15 14:31 2022-08-01 16:31
Reporter myllynen View Status public  
Assigned To
Priority normal Resolution Rejected  
Status Closed  
Name Marko Myllynen
Organization Self
User Reference
Section strftime
Page Number N
Line Number N
Interp Status ---
Final Accepted Text
Summary 0000772: New time zone conversion specifier character
Description The national recommendations in Finland for Finnish concerning date strings containing timezone state that they should use format like "UTC+3" or "UTC+5.30" [1] (this is also the format lots of web sites are using today).

1) http://kotoistus.fi/suositukset/vahv_kalenterit_cldr1_4.htm#Kellonajat [^]

strftime's %z prints something like "+0300" but this clearly does not match the recommendations.
Desired Action Add an extension which would allow constructing date strings based on Finnish recommendations.

FWIW, with GNU date one can get "UTC+03" by using the "UTC%:::z" format string which is much closer "UTC+3" (but still not quite as recommended).
Tags No tags attached.
Attached Files

- Relationships

-  Notes
(0001905)
geoffclare (manager)
2013-10-15 14:55

Timezone names of the requested form are already supported. As
explained in XRAT A.8.3:

    TZ

    The quoted form of the timezone variable allows timezone names of
    the form UTC+1 (or any name that contains the character plus
    ('+'), the character minus ('-'), or digits), which may be
    appropriate for countries that do not have an official timezone
    name. It would be coded as <UTC+1>+1<UTC+2>, which would cause std
    to have a value of UTC+1 and dst a value of UTC+2, each with a
    length of 5 characters.

Example:

$ TZ="<UTC+03>+3<UTC+04>" date
Tue Oct 15 12:53:11 UTC+04 2013
(0002048)
geoffclare (manager)
2013-12-05 16:19
edited on: 2013-12-05 16:19

In the Dec 5th teleconference the group decided to reject this request based on Note: 0001905 and the fact that the requested feature does not have any current implementations.

(0002057)
myllynen (reporter)
2013-12-09 15:09

Sorry for reopening but I had missed the previous update and just want to add the following for the record - please feel free to reclose if deemed appropriate. Thanks.

GNU date was used above as an example how to get closer to the desired result. However without a suitable strftime conversion specifier character available it seems impossible for example to create a locale file for fi_FI which would comply with the recommendations thus affecting a wide range of applications and users, thus the issue is not being limited to date only.
(0002058)
shware_systems (reporter)
2013-12-09 19:48

What appears to be missing is not a separate conversion specifier character, but a description how this function is TZ sensitive with respect to the 'z' and 'Z' specifiers that at least refers to XBD 8.3 or XRAT A.8.3.
I agree there appears to be a larger issue that the LC_TIME section of locale definitions has no 'tz_' prefix keywords to relate a locale to a particular offset from GMT so setlocale() can set TZ appropriately, or a pseudo-TZ can be constructed when using strftime_l(). For countries with more than one timezone, a locale specifier string such as fi_FI, or en_US, doesn't have a field to pick a particular standardized time zone either. The 'C' locale presumes everything is GMT with no DST, it looks. That's a separate ERN for Issue 8, though. For this as TC2, it seems the 'Z' specifier is supposed to be the one that is sensitive, while 'z' is for the standard format only, but that isn't clear as TZ is how POSIX defines what the C standard leaves as implementation defined.

For clarity, changing Line 64674:
"Z Replaced by the timezone name or abbreviation, or by no bytes if no timezone
information exists. [tm_isdst]"

to:
"Z Replaced by the timezone name or abbreviation as specified by the TZ environment variable (See XBD 8.3), or by no bytes if no timezone information exists. [tm_isdst]"

At Line 64892, Change to:
"XBD Section 7.3.5 (on page 159), Section 8.3 (on page 179, "TZ"), <time.h>"

I can see adding 'L' as a CX specifier that allows a format string flag that the tm parameter is NOT localtime but GMT and the appropriate locale based timezone offset should be applied for reporting all the other specifiers. Changing the definition of tm_isdst to hold both a TZ_DST and TZ_GDT flags is also plausible, but wouldn't be backwards compatible and probably have to be coordinated with the C standard.

- Issue History
Date Modified Username Field Change
2013-10-15 14:31 myllynen New Issue
2013-10-15 14:31 myllynen Name => Marko Myllynen
2013-10-15 14:31 myllynen Organization => Self
2013-10-15 14:31 myllynen Section => strftime
2013-10-15 14:31 myllynen Page Number => N
2013-10-15 14:31 myllynen Line Number => N
2013-10-15 14:55 geoffclare Note Added: 0001905
2013-12-05 16:19 geoffclare Interp Status => ---
2013-12-05 16:19 geoffclare Note Added: 0002048
2013-12-05 16:19 geoffclare Status New => Closed
2013-12-05 16:19 geoffclare Resolution Open => Rejected
2013-12-05 16:19 geoffclare Note Edited: 0002048
2013-12-09 15:09 myllynen Note Added: 0002057
2013-12-09 15:09 myllynen Status Closed => Under Review
2013-12-09 15:09 myllynen Resolution Rejected => Reopened
2013-12-09 19:48 shware_systems Note Added: 0002058
2022-08-01 16:31 Don Cragun Status Under Review => Closed
2022-08-01 16:31 Don Cragun Resolution Reopened => Rejected


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker