|Anonymous | Login||2020-08-13 12:02 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0000772||[1003.1(2013)/Issue7+TC1] System Interfaces||Editorial||Enhancement Request||2013-10-15 14:31||2013-12-09 19:48|
|Final Accepted Text|
|Summary||0000772: New time zone conversion specifier character|
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"  (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.
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.|
Timezone names of the requested form are already supported. As
explained in XRAT A.8.3:
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.
$ TZ="<UTC+03>+3<UTC+04>" date
Tue Oct 15 12:53:11 UTC+04 2013
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.
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.
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]"
"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.
|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|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|