From: Max Nikulin <manikulin@gmail.com>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: orgmode <emacs-orgmode@gnu.org>, 54764@debbugs.gnu.org
Subject: Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones
Date: Wed, 20 Apr 2022 23:56:15 +0700 [thread overview]
Message-ID: <8ba9e258-dd24-a0a0-1aa6-9c2831c05af0@gmail.com> (raw)
In-Reply-To: <3624beb8-71fd-924e-a065-74d0034ed351@cs.ucla.edu>
On 17/04/2022 08:58, Paul Eggert wrote:
> Thanks, I installed that and then installed the attached, which merges
> that with some documentation improvements that I drafted based on this
> thread.
Thank you for further editing of docs. Please, fix a typo.
> diff --git a/doc/lispref/os.texi b/doc/lispref/os.texi
> index 66689f43a9..8366689640 100644
> --- a/doc/lispref/os.texi
> +++ b/doc/lispref/os.texi
>
> @@ -1687,14 +1660,18 @@ Time Conversion
> than six arguments the @emph{last} argument is used as @var{zone} and
> any other extra arguments are ignored, so that @code{(apply
> #'encode-time (decode-time ...))} works. In this obsolescent
> -convention, @var{zone} defaults to the current time zone rule
> -(@pxref{Time Zone Rules}), and @var{dst} is treated as if it was
> -@minus{}1.
> +convention, @var{dst} is @minus{}1 and @var{zone} defaults to the
> +current time zone rule (@pxref{Time Zone Rules}).
> +When modernizing an obsolescent caller, ensure that the more-modern
> +list equivalent contains 9 elements with a a @code{dst} element that
^^^
A typo: double "a".
> +is @minus{}1, not @code{nil}.
>
> +@lisp
> +;; Try to compute the time four years from now.
> +;; Watch out; this might not work as expected.
> +(let ((time (decode-time)))
> + (setf (decoded-time-year time)
> + (+ (decoded-time-year time) 4))
> + time)
> +@end lisp
> +@noindent
> +Unfortunately, this code might not work as expected if the resulting
> +time is invalid due to daylight saving transitions, time zone changes,
> +or missing leap days or leap seconds. For example, if executed on
> +February 29, 2096 this code yields a nonexistent date because 2100 is
> +not a leap year. To avoid some (though not all) of the problem, you
> +can base calculations on the middle of the affected unit, e.g., start
> +at July 1 when adding years.
If I get your idea correctly then "January, 31" + "1 month" should be
more impressive as impossible date. Year 2096 is too far in future. I am
unsure concerning expectation. Overflow arithmetic is described above
and e.g. JavaScript normalizes Date object in a similar fashion. The
special point is that elisp decoded time requires explicit normalization
however and 2100 is a good example that updating of any field may
"break" the date.
> Alternatively, you can use the
> +@file{calendar} and @file{time-date} libraries.
A remark loosely related to your patch. Earlier you mentioned missed
midnight due to time transition and suggested to use calendrical
functions in Org. I can not figure out which elisp function can help to
determine wall time for Aug 1 start of day in Cairo:
Africa/Cairo Thu Jul 31 21:59:59 2014 UT = Thu Jul 31 23:59:59 2014 EET
isdst=0 gmtoff=7200
Africa/Cairo Thu Jul 31 22:00:00 2014 UT = Fri Aug 1 01:00:00 2014
EEST isdst=1 gmtoff=10800
input: 2014-08-01 Africa/Cairo
(timezone may be implicit as the system one)
expected output: 01:00:00
next prev parent reply other threads:[~2022-04-20 17:12 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-07 12:37 Max Nikulin
2022-04-09 7:52 ` Paul Eggert
2022-04-10 3:57 ` Max Nikulin
2022-04-13 14:40 ` Max Nikulin
2022-04-13 18:35 ` Paul Eggert
2022-04-14 13:19 ` Max Nikulin
2022-04-14 22:46 ` Paul Eggert
2022-04-15 2:14 ` Tim Cross
2022-04-15 17:23 ` Max Nikulin
2022-04-16 19:23 ` Paul Eggert
2022-04-21 16:59 ` Max Nikulin
2022-04-19 2:02 ` Paul Eggert
2022-04-19 5:50 ` Eli Zaretskii
2022-04-19 22:22 ` Paul Eggert
2022-04-20 7:23 ` Eli Zaretskii
2022-04-20 18:19 ` Paul Eggert
2022-04-20 18:41 ` Eli Zaretskii
2022-04-20 19:01 ` Paul Eggert
2022-04-20 19:14 ` Eli Zaretskii
2022-04-20 19:23 ` Paul Eggert
2022-04-20 19:30 ` Eli Zaretskii
2022-04-21 0:11 ` Paul Eggert
2022-04-21 6:44 ` Eli Zaretskii
2022-04-21 23:56 ` Paul Eggert
2022-04-22 5:01 ` Eli Zaretskii
2022-04-23 14:35 ` Bernhard Voelker
2022-04-20 15:07 ` Max Nikulin
2022-04-20 18:29 ` Paul Eggert
2022-04-25 15:30 ` Max Nikulin
2022-04-25 15:37 ` Paul Eggert
2022-04-25 19:49 ` Paul Eggert
2022-04-30 11:22 ` Max Nikulin
2022-05-01 2:32 ` Paul Eggert
2022-05-01 17:15 ` Max Nikulin
2022-04-13 15:12 ` Max Nikulin
2022-04-16 16:26 ` Max Nikulin
2022-04-17 1:58 ` Paul Eggert
2022-04-20 16:56 ` Max Nikulin [this message]
2022-04-20 19:17 ` Paul Eggert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8ba9e258-dd24-a0a0-1aa6-9c2831c05af0@gmail.com \
--to=manikulin@gmail.com \
--cc=54764@debbugs.gnu.org \
--cc=eggert@cs.ucla.edu \
--cc=emacs-orgmode@gnu.org \
--subject='Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox:
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).