[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#54764: encode-time: make DST and TIMEZONE fields of the list argumen
From: |
Max Nikulin |
Subject: |
bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones |
Date: |
Mon, 2 May 2022 00:15:17 +0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 |
On 01/05/2022 09:32, Paul Eggert wrote:
On 4/30/22 04:22, Max Nikulin wrote:
I posted a corrected version of my `org-encode-time' macro, but I did
not add you to Cc (I sent reply through news.gmane.io), and it has no
special case to check whether `encode-time' supports 6 elements list
argument:
As I understand it, org-encode-time is intended to be a compatibility
function like org-newline-and-indent and org-string-distance. Those are
in org-compat.el, so I assumed org-encode-time would be there too.
Maybe you are right. I believe that it should do a bit more than just
ensure compatibility. An additional goal is to avoid pitfall with list
vs. separate arguments result discrepancy:
(format-time-string
"%F %T %z %Z"
(encode-time 0 30 23 31 3 2022 nil nil "Europe/Madrid")
"Europe/Madrid")
"2022-03-31 23:30:00 +0200 CEST"
(format-time-string
"%F %T %z %Z"
(encode-time '(0 30 23 31 3 2022 nil nil "Europe/Madrid"))
"Europe/Madrid")
"2022-04-01 00:30:00 +0200 CEST"
Also, if the intent is to emulate Emacs 29 encode-time, can't we do
something like the attached instead? The idea is to implement Emacs 29
encode-time both on pre-29 Emacs (that don't support lists of length 6)
and post-29 Emacs (which might drop support for the obsolescent form).
+(if (ignore-errors (encode-time '(0 0 0 1 1 1971)))
+ (if (ignore-errors (encode-time 0 0 0 1 1 1971))
+ (defalias 'org-encode-time #'encode-time)
+ (defun org-encode-time (time &rest args)
+ (encode-time (if args (cons time args) time))))
+ (defun org-encode-time (time &rest args)
+ (if args
+ (apply #'encode-time time args)
+ (apply #'encode-time time))))
1. I would prefer macro since it works at compile or load time, so
runtime impact is minimal.
2. Your variant may be fixed, but currently I do not like behavior for
Emacs-27. Compare encode-time and org-encode-time with new calling style:
(format-time-string
"%F %T %z %Z"
(encode-time '(0 30 23 31 3 2022 nil nil "Europe/Madrid"))
"Europe/Madrid")
"2022-04-01 00:30:00 +0200 CEST"
(format-time-string
"%F %T %z %Z"
(org-encode-time '(0 30 23 31 3 2022 nil nil "Europe/Madrid"))
"Europe/Madrid")
"2022-03-31 23:30:00 +0200 CEST"
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones,
Max Nikulin <=