[PROPOSED] date +%z now outputs -0000 for uninhabited
When the time zone has UT offset 0 and the time zone abbreviation begins with "-", the %z spec now expands to -0000 instead of to +0000. This conveys more-useful info, and is what the next version of GNU 'date' is intended to do. * NEWS, newstrftime.3: Document change. * date.1: Document %z. * strftime.c (_fmt): Implement change. --- NEWS | 4 ++++ date.1 | 1 + newstrftime.3 | 12 ++++++++++++ strftime.c | 13 ++++++++++++- 4 files changed, 29 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index 8276cc7..3975295 100644 --- a/NEWS +++ b/NEWS @@ -74,6 +74,10 @@ Unreleased, experimental changes when TZ is set to a POSIX-style string that specifies DST. (Problem reported by Kees Dekker.) + date and strftime now cause %z to generate "-0000" instead of + "+0000" when the UT offset is zero and the time zone abbreviation + begins with "-". + Changes to documentation and commentary tz-link.htm now covers leap smearing, which is popular in clouds. diff --git a/date.1 b/date.1 index 7fd4848..579ab92 100644 --- a/date.1 +++ b/date.1 @@ -90,6 +90,7 @@ to be output in a particular way %X 14:54:40 Time* %y 89 Last two digits of year %Y 1989 Year in full +%z -0500 Numeric time zone %Z EST Time zone abbreviation %+ Wed Mar 8 14:54:40 EST 1989 Default output format* .if t .in -.5i diff --git a/newstrftime.3 b/newstrftime.3 index 9a60ee3..8f1be34 100644 --- a/newstrftime.3 +++ b/newstrftime.3 @@ -50,6 +50,13 @@ strftime \- format date and time .SH DESCRIPTION .ie '\(en'' .ds en \- .el .ds en \(en +.ie '\(lq'' .ds lq \&"\" +.el .ds lq \(lq\" +.ie '\(rq'' .ds rq \&"\" +.el .ds rq \(rq\" +.de q +\\$3\*(lq\\$1\*(rq\\$2 +.. The .I strftime function formats the information from @@ -211,6 +218,11 @@ is replaced by the offset from the Prime Meridian in the format +HHMM or \*-HHMM as appropriate, with positive values representing locations east of Greenwich, or by the empty string if this is not determinable. +The numeric time zone \*-0000 is used when the time is Universal Time +but local time is indeterminate; by convention this is used for +locations while uninhabited, and corresponds to a zero offset when the +time zone abbreviation begins with +.q "\*-" . .TP %% is replaced by a single %. diff --git a/strftime.c b/strftime.c index 984ead5..2bfb6c1 100644 --- a/strftime.c +++ b/strftime.c @@ -500,6 +500,7 @@ label: { long diff; char const * sign; + bool negative; # ifdef TM_GMTOFF diff = t->TM_GMTOFF; @@ -538,7 +539,17 @@ label: continue; # endif # endif - if (diff < 0) { + negative = diff < 0; + if (diff == 0) { +#ifdef TM_ZONE + negative = t->TM_ZONE[0] == '-'; +#else + negative + = (t->tm_isdst < 0 + || tzname[t->tm_isdst != 0][0] == '-'); +#endif + } + if (negative) { sign = "-"; diff = -diff; } else sign = "+"; -- 2.7.4
I think that might give cause for confusion with respect to RFC3339 style string formatting, section 4.3: 4.3. Unknown Local Offset Convention If the time in UTC is known, but the offset to local time is unknown,
this can be represented with an offset of "-00:00". This differs semantically from an offset of "Z" or "+00:00", which imply that UTC is the preferred reference point for the specified time.
That's not what we intend to convey in this case, is it? I realize that the we're not trying to output RFC3339, but I think it could lead to confusion. Jon On 15 January 2017 at 08:48, Paul Eggert <eggert@cs.ucla.edu> wrote:
When the time zone has UT offset 0 and the time zone abbreviation begins with "-", the %z spec now expands to -0000 instead of to +0000. This conveys more-useful info, and is what the next version of GNU 'date' is intended to do. * NEWS, newstrftime.3: Document change. * date.1: Document %z. * strftime.c (_fmt): Implement change. --- NEWS | 4 ++++ date.1 | 1 + newstrftime.3 | 12 ++++++++++++ strftime.c | 13 ++++++++++++- 4 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/NEWS b/NEWS index 8276cc7..3975295 100644 --- a/NEWS +++ b/NEWS @@ -74,6 +74,10 @@ Unreleased, experimental changes when TZ is set to a POSIX-style string that specifies DST. (Problem reported by Kees Dekker.)
+ date and strftime now cause %z to generate "-0000" instead of + "+0000" when the UT offset is zero and the time zone abbreviation + begins with "-". + Changes to documentation and commentary
tz-link.htm now covers leap smearing, which is popular in clouds. diff --git a/date.1 b/date.1 index 7fd4848..579ab92 100644 --- a/date.1 +++ b/date.1 @@ -90,6 +90,7 @@ to be output in a particular way %X 14:54:40 Time* %y 89 Last two digits of year %Y 1989 Year in full +%z -0500 Numeric time zone %Z EST Time zone abbreviation %+ Wed Mar 8 14:54:40 EST 1989 Default output format* .if t .in -.5i diff --git a/newstrftime.3 b/newstrftime.3 index 9a60ee3..8f1be34 100644 --- a/newstrftime.3 +++ b/newstrftime.3 @@ -50,6 +50,13 @@ strftime \- format date and time .SH DESCRIPTION .ie '\(en'' .ds en \- .el .ds en \(en +.ie '\(lq'' .ds lq \&"\" +.el .ds lq \(lq\" +.ie '\(rq'' .ds rq \&"\" +.el .ds rq \(rq\" +.de q +\\$3\*(lq\\$1\*(rq\\$2 +.. The .I strftime function formats the information from @@ -211,6 +218,11 @@ is replaced by the offset from the Prime Meridian in the format +HHMM or \*-HHMM as appropriate, with positive values representing locations east of Greenwich, or by the empty string if this is not determinable. +The numeric time zone \*-0000 is used when the time is Universal Time +but local time is indeterminate; by convention this is used for +locations while uninhabited, and corresponds to a zero offset when the +time zone abbreviation begins with +.q "\*-" . .TP %% is replaced by a single %. diff --git a/strftime.c b/strftime.c index 984ead5..2bfb6c1 100644 --- a/strftime.c +++ b/strftime.c @@ -500,6 +500,7 @@ label: { long diff; char const * sign; + bool negative;
# ifdef TM_GMTOFF diff = t->TM_GMTOFF; @@ -538,7 +539,17 @@ label: continue; # endif # endif - if (diff < 0) { + negative = diff < 0; + if (diff == 0) { +#ifdef TM_ZONE + negative = t->TM_ZONE[0] == '-'; +#else + negative + = (t->tm_isdst < 0 + || tzname[t->tm_isdst != 0][0] == '-'); +#endif + } + if (negative) { sign = "-"; diff = -diff; } else sign = "+"; -- 2.7.4
Jon Skeet wrote:
If the time in UTC is known, but the offset to local time is unknown, this can be represented with an offset of "-00:00". This differs semantically from an offset of "Z" or "+00:00", which imply that UTC is the preferred reference point for the specified time. That's not what we intend to convey in this case, is it?
No, it's pretty much what we want to convey. In the case in question, the time in UTC is known, and local time is undefined which means it is unknown. An example is Antarctica/Troll before 2005, when Troll Station was uninhabited.
On 15 Jan 2017 09:19, "Paul Eggert" <eggert@cs.ucla.edu> wrote: Jon Skeet wrote:
If the time in UTC is known, but the offset to local time is unknown,
this can be represented with an offset of "-00:00". This differs semantically from an offset of "Z" or "+00:00", which imply that UTC is the preferred reference point for the specified time.
That's not what we intend to convey in this case, is it?
No, it's pretty much what we want to convey. In the case in question, the time in UTC is known, and local time is undefined which means it is unknown. An example is Antarctica/Troll before 2005, when Troll Station was uninhabited Fair enough - that makes sense. Will have to check whether this will need a change in Noda Time... Jon
In e-mail, a zone of -0000 is intended to mean that the date/time given is in the sender's local time, but there is no information available about what that would be in UTC (no available timezone info). It is intended for systems that keep only local time (if any of those remain these days.) kre
On 01/15/2017 04:57 AM, Robert Elz wrote:
In e-mail, a zone of -0000 is intended to mean that the date/time given is in the sender's local time, but there is no information available about what that would be in UTC (no available timezone info). It is intended for systems that keep only local time (if any of those remain these days.)
Yes, that's what's in RFC 5322, and it differs from what's in RFC 3339. The RFC 3339 interpretation is better for the more-typical case today, where UTC is known but local time might not be known or might be undefined. Also, the RFC 3339 interpretation is stricter, in the sense that a RFC 3339 sender of -0000 is compatible with an RFC 5322 receiver of -0000, whereas the reverse is not true; and this means it's better to use RFC 3339 when generating -0000, as is the case here.
participants (3)
-
Jon Skeet -
Paul Eggert -
Robert Elz