GNU bug report logs - #52934
format-time-string year error

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 52934 in the body.
You can then email your comments to 52934 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: <david <at> ngdr.net>
To: <bug-gnu-emacs <at> gnu.org>
Subject: format-time-string year error
Date: Sat, 01 Jan 2022 13:11:56 -0700

;; I ran this in the *scratch* buffer at lunch time in Denver.
;; The year is not right.
(defun  doit  ()
  (format  "%s\n%s\n%s"          
           (current-time)
           (format-time-string  "%d %b")
           (format-time-string  "%R %G")))
(doit)
"(25040 45621 647344 602000)
01 Jan
12:57 2021"

Message #8 received at 52934 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: "david <at> ngdr.net" <david <at> ngdr.net>, "52934 <at> debbugs.gnu.org"
 <52934 <at> debbugs.gnu.org>
Subject: RE: [External] : bug#52934: format-time-string year error
Date: Sat, 1 Jan 2022 20:16:46 +0000

Confirmed, for this build at least:

In GNU Emacs 27.2 (build 1, x86_64-w64-mingw32)
 of 2021-03-26 built on CIRROCUMULUS
Repository revision: deef5efafb70f4b171265b896505b92b6eef24e6
Repository branch: HEAD
Windowing system distributor 'Microsoft Corp.', version 10.0.19042
System Description: Microsoft Windows 10 Pro (v10.0.2009.19042.1348)

Message #11 received at 52934 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: <david <at> ngdr.net>
Cc: 52934 <at> debbugs.gnu.org
Subject: Re: bug#52934: format-time-string year error
Date: Sat, 01 Jan 2022 22:25:59 +0200

> Date: Sat, 01 Jan 2022 13:11:56 -0700
> From: <david <at> ngdr.net>
> 
> ;; I ran this in the *scratch* buffer at lunch time in Denver.
> ;; The year is not right.
> (defun  doit  ()
>   (format  "%s\n%s\n%s"          
>            (current-time)
>            (format-time-string  "%d %b")
>            (format-time-string  "%R %G")))
> (doit)
> "(25040 45621 647344 602000)
> 01 Jan
> 12:57 2021"

The doc string of format-time-string says:

  %G is the year corresponding to the ISO week

Isn't it true that the ISO week is still in 2021 today?

Message #14 received at 52934 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 52934 <at> debbugs.gnu.org, david <at> ngdr.net
Subject: Re: bug#52934: format-time-string year error
Date: Sat, 01 Jan 2022 23:21:25 +0100

On Jan 01 2022, Eli Zaretskii wrote:

>> Date: Sat, 01 Jan 2022 13:11:56 -0700
>> From: <david <at> ngdr.net>
>> 
>> ;; I ran this in the *scratch* buffer at lunch time in Denver.
>> ;; The year is not right.
>> (defun  doit  ()
>>   (format  "%s\n%s\n%s"          
>>            (current-time)
>>            (format-time-string  "%d %b")
>>            (format-time-string  "%R %G")))
>> (doit)
>> "(25040 45621 647344 602000)
>> 01 Jan
>> 12:57 2021"
>
> The doc string of format-time-string says:
>
>   %G is the year corresponding to the ISO week
>
> Isn't it true that the ISO week is still in 2021 today?

Week 52 of 2021 started on 2021-12-27, and ends on 2022-01-02.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Message #17 received at 52934 <at> debbugs.gnu.org (full text, mbox):

From: <david <at> ngdr.net>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 52934 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#52934: format-time-string year error
Date: Sat, 01 Jan 2022 16:01:21 -0700

Now I have read about ISO 8601 in Wikipedia and, of course, your replies
are correct; now I know that we are in week 52 of 2021.

However, someone writing Emacs code to produce a timestamp for, e.g.,
.html code, does not see the need to study an ISO specification to avoid a
tripwire that is not even obvious - the problem only occurs, if it occurs,
in a few days of the year.  Otherwise there is no reason to suspect that
personal code is faulty: it will perform correctly, including under test,
for about 360 days of the year.

I should like to suggest a note in the Emacs Info documentation that warns
the reader that ISO weeks do not map nicely into the calendar that the
reader lives by.  That would be helpful.  I am not suggesting that the
Emacs documentation should describe ISO 8601, only that it warns of the
potential problems, and, ideally, gives a reference to a description of the
standard.

dajo

Message #22 received at 52934-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: <david <at> ngdr.net>
Cc: 52934-done <at> debbugs.gnu.org, schwab <at> linux-m68k.org
Subject: Re: bug#52934: format-time-string year error
Date: Sun, 02 Jan 2022 09:32:49 +0200

> Date: Sat, 01 Jan 2022 16:01:21 -0700
> From: <david <at> ngdr.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, <52934 <at> debbugs.gnu.org>
> 
> Now I have read about ISO 8601 in Wikipedia and, of course, your replies
> are correct; now I know that we are in week 52 of 2021.
> 
> However, someone writing Emacs code to produce a timestamp for, e.g.,
> .html code, does not see the need to study an ISO specification to avoid a
> tripwire that is not even obvious - the problem only occurs, if it occurs,
> in a few days of the year.  Otherwise there is no reason to suspect that
> personal code is faulty: it will perform correctly, including under test,
> for about 360 days of the year.
> 
> I should like to suggest a note in the Emacs Info documentation that warns
> the reader that ISO weeks do not map nicely into the calendar that the
> reader lives by.  That would be helpful.  I am not suggesting that the
> Emacs documentation should describe ISO 8601, only that it warns of the
> potential problems, and, ideally, gives a reference to a description of the
> standard.

I enhanced the documentation, thanks.  Pointing to the ISO standard
would not be useful, since it is  not freely available, so I said
something about the rules instead.

I'm therefore closing this bug.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.