Anonymous | Login | 2024-04-18 14:17 UTC |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||
ID | Category | Severity | Type | Date Submitted | Last Update | ||
0000949 | [1003.1(2013)/Issue7+TC1] Shell and Utilities | Editorial | Clarification Requested | 2015-05-12 07:06 | 2016-02-04 16:56 | ||
Reporter | dannyniu | View Status | public | ||||
Assigned To | |||||||
Priority | normal | Resolution | Rejected | ||||
Status | Closed | ||||||
Name | DannyNiu/NJF | ||||||
Organization | |||||||
User Reference | |||||||
Section | the date utility | ||||||
Page Number | 26000 | ||||||
Line Number | 84323 | ||||||
Interp Status | --- | ||||||
Final Accepted Text | |||||||
Summary | 0000949: The timezone name might be non-unique. | ||||||
Description |
As I wonderred through the web to learn what a.m. and p.m. mean, I happened to know that timezone abbreviations might not be unique. For example, CST could mean either China Standard Time, Central Standard Time (USA or Australia), and Central Summer Time. And so, I fear that time strings produced by the same operating system, deployed in different locations might cause confusion. |
||||||
Desired Action | Clarify the standard that is being referred to for timezone names, and/or require an option that produces an unambiguous string such as UTC+8. | ||||||
Tags | No tags attached. | ||||||
Attached Files | |||||||
|
Notes | |
(0002665) shware_systems (reporter) 2015-05-12 23:03 |
There is no standard referred to, the TZ variable simply has to be in the defined format and selection of names is left to the operator. This is adequate to the needs of the current interfaces and standard utilities. As some time zones have multiple names, to fully support a names database would require geographic coordinates along with difference from GMT value, plus sensitivity to the whims of various governments on when daylight savings time starts and ends, to perform arbitrary conversions, and would affect a number of interfaces. In recent discussions the basic consensus was these issues placed such support as outside of the scope for POSIX to mandate. As it is, interfaces like strftime have the %z format for producing a numeric offset string when presented data returned by localtime() and %s can be used to output the std and dst strings in tznames[], as an alternative to examining TZ directly. |
(0002666) joerg (reporter) 2015-05-13 09:30 |
BTW: it would be nice if we had a system that would finally allow a correct localization, see e.g.: TZ=MEZ date Mittwoch, 13. Mai 2015, 09:27:39 Uhr GMT TZ=MESZ date Mittwoch, 13. Mai 2015, 09:27:42 Uhr GMT So using two correct (according to the time law) timezone names do not work but a non-localized name works: TZ=MET date Mittwoch, 13. Mai 2015, 11:30:02 Uhr MEST |
(0002667) vapier (reporter) 2015-05-13 16:31 |
while such desires are reasonable, all of it is out of scope for POSIX, and this report should be rejected and such |
(0002673) dannyniu (reporter) 2015-05-21 07:36 edited on: 2015-05-21 07:45 |
I happen to dug up this: http://austingroupbugs.net/view.php?id=772 [^] , and this: http://austingroupbugs.net/view.php?id=661 [^] Perhaps considering in the Rationales volume recommending each national standard body define their own variant of 'date'? |
(0003066) nick (manager) 2016-02-04 16:56 |
The timezone names are set by local conventions and government authorities and are not unique. The POSIX standards cannot override government and local conventions. Applications that want to use UTC as their timezone can invoke utilities with TZ=UTC0. If an application wants to use something like TZ=<UTC-6>6<UTC-5> to specify the local name in a manner different form local conventions, that application needs to also understand local conventions for when daylight savings time applies. |
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |