bug#52934: format-time-string year error

bug#52934: format-time-string year error

[david]

;; 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"

bug#52934: [External] : bug#52934: format-time-string year error

[Drew Adams]

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)

bug#52934: format-time-string year error

[Eli Zaretskii]

> Date: Sat, 01 Jan 2022 13:11:56 -0700
> From: <david@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?

bug#52934: format-time-string year error

[Andreas Schwab]

On Jan 01 2022, Eli Zaretskii wrote:

>> Date: Sat, 01 Jan 2022 13:11:56 -0700
>> From: <david@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@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#52934: format-time-string year error

[david]

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

bug#52934: format-time-string year error

[Eli Zaretskii]

> Date: Sat, 01 Jan 2022 16:01:21 -0700
> From: <david@ngdr.net>
> Cc: Eli Zaretskii <eliz@gnu.org>, <52934@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.