Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones
Paul Eggert writes: > On 4/14/22 06:19, Max Nikulin wrote: > >> date-time + "America/Los_Angeles" input should not be reduced to timezone >> offset >> in the output. > > It depends on the application. For some applications (e.g., generating > "Date:" lines > in email), it is entirely correct to output a timestamp like "14 Apr 2022 > 15:16:04 > -0700", thus losing the fact that the timestamp was generated with > TZ="America/Los_Angeles". > >> Zone internal object or identifier is important for calculation of other >> date-time values based on the origin value. > > Again, that depends on the application. It's typically wrong to store an old > timestamp in a form like "1950-07-01 00:00 Europe/Lisbon", because there is no > standard for what "Europe/Lisbon" means. If you update your copy of TZDB, or > interpret such a timestamp on another computer, that can change the > interpretation of > such a timestamp. In this particular case, a change in TZDB release 2021b > altered the > interpretation of this old timestamp because we discovered that DST was > observed in > 1950 in Portugal. > > If you want to keep the TZDB identifier for advice about how to interpret > dates > relative to a timestamp, that's fine. But you should keep the UT offset in > addition > to the TZDB identifier, if you want your app to be fully accurate and useful. > For > example, you should store "1950-07-01 00:00:00 + Europe/Lisbon" for a > timestamp > generated by TZDB release 2021a, so that when you interpret the timestamp in > release > 2021b you'll have an idea of what you're dealing with. > I think this is a very important point. Timezone data is not static. If you only record the timezone name, offsets will be calculated using the current definition, which may not be correct for past timestamps. A good example of this is the DST values and the date when a TZ transitions between DST and non-DST periods. That date can change, either temporarily or permanently. That change can be days or even weeks. Any date related calculations which only have knowledge about TZ names and not the specific offset of a timestamp can therefore be out by a significant amount.
Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones
On 4/14/22 06:19, Max Nikulin wrote: date-time + "America/Los_Angeles" input should not be reduced to timezone offset in the output. It depends on the application. For some applications (e.g., generating "Date:" lines in email), it is entirely correct to output a timestamp like "14 Apr 2022 15:16:04 -0700", thus losing the fact that the timestamp was generated with TZ="America/Los_Angeles". Zone internal object or identifier is important for calculation of other date-time values based on the origin value. Again, that depends on the application. It's typically wrong to store an old timestamp in a form like "1950-07-01 00:00 Europe/Lisbon", because there is no standard for what "Europe/Lisbon" means. If you update your copy of TZDB, or interpret such a timestamp on another computer, that can change the interpretation of such a timestamp. In this particular case, a change in TZDB release 2021b altered the interpretation of this old timestamp because we discovered that DST was observed in 1950 in Portugal. If you want to keep the TZDB identifier for advice about how to interpret dates relative to a timestamp, that's fine. But you should keep the UT offset in addition to the TZDB identifier, if you want your app to be fully accurate and useful. For example, you should store "1950-07-01 00:00:00 + Europe/Lisbon" for a timestamp generated by TZDB release 2021a, so that when you interpret the timestamp in release 2021b you'll have an idea of what you're dealing with. I want hints like "in the case of ambiguity resolve to transition time immediately before/immediately after transition" or "provide suitable time prior to/after to transition". Although that might be nice it's not what mktime gives us, and I doubt whether it's a good idea to try to implement it from scratch in Emacs. I hope, they may work without explicitly providing time zone offset to the input that anyway requires additional calculations. It doesn't require additional calculations on the Emacs Lisp user's part. All you need to do is save the UT offset, and use it later. There's so little overhead to this that it's not worth worrying about. ±n hours may mean ±n*3600 seconds or time with same minutes and seconds values but hours value is changed by n even if a 30 min DST transition happens in between. Sorry, I don't understand what this sentence is intended to mean. `parse-time-string' has another set of problems. Sure, but that was just an example. You can write your own date parser. The point is that when you save a localtime timestamp, you should save its UT offset too, in whatever notation is appropriate. UTC offset is another feature and implementing the hints I have tried to describe may require implementing from scratch full stack of time handling functions. I doubt whether that's a good idea. I've written that sort of code, and it's a lot more work than one might think and it's notoriously difficult to do it correctly. You have better things to do. So I still do not see any point in mandatory DST and ZONE fields in new interface of `encode-time'. I think we're in agreement here. As I mentioned earlier, I plan to modify Emacs encode-time so that you can pass it a 6-arg list as well as an 9-arg list. Once this change is in, the DST and ZONE fields will not be mandatory.
Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones
On 14/04/2022 01:35, Paul Eggert wrote: On 4/13/22 07:40, Max Nikulin wrote: I do not see a way to get 23:30 EAT +0300. Are you asking for a function F where you say, "I want to give F a possibly-ambiguous decoded local time D, and for F to return all timestamps that map to D"? If so, encode-time doesn't do that, because the underlying C API (namely, mktime) doesn't do that. All mktime and encode-time do is give you *one* timestamp that maps to D; it won't give you any other timestamps. I am just trying to convince you that new API still can not handle ambiguities in response to: Unfortunately it makes the function more convenient to use incorrectly. This was part of the motivation for the API change. The obsolescent calling convention has no way to deal with ambiguous timestamps like 2022-11-06 01:30 when TZ="America/Los_Angeles". Completely ignoring DST in old API is a bug. Possibility to omit DST and ZONE is a feature for convenience and it is not related to correctly/incorrectly. It has no common with allowing 6-values SECONONDS...YEAR list. I am aware of mktime and my opinion is that libc in such cases (dealing with formats for humans) is hardly usable for applications more complex than "hello world". I do not want all ambiguous time values. I want to provide hints how they should be resolved and get in response an additional value that says in which way it is actually resolved. If you're worried about possibly-ambiguous decoded local times, you could probe (say) one day before and one day after encode-time's result to see if the UTC offset changes, and let that guide you to find other possible timestamps that map to the decoded time. Although this is just a heuristic it should be good enough. I would prefer to avoid dances with +/-1 day timestamps. I would not be surprised when one day they will give wrong result. During computations it is available to which interval of time current time offset is valid. Such value may be included in result of conversion. So date-time + "America/Los_Angeles" input should not be reduced to timezone offset in the output. Zone internal object or identifier is important for calculation of other date-time values based on the origin value. I doubt whether you need to do that, though. Code that is not careful about local time offsets doesn't care how ambiguous decoded times are resolved. And code that does care should record UTC offsets anyway, and you can use those offsets to disambiguate the decoded times. Something like this, say: (defun encode-and-format-time (time tz) (let ((etime (encode-time (parse-time-string time (format-time-string "%F %T %Z %z" etime tz))) With this definition, (encode-and-format-time "2021-01-31 23:30:00 +0300" "Africa/Juba") yields "2021-01-31 23:30:00 EAT +0300", which is the timestamp you want. I want hints like "in the case of ambiguity resolve to transition time immediately before/immediately after transition" or "provide suitable time prior to/after to transition". I hope, they may work without explicitly providing time zone offset to the input that anyway requires additional calculations. ±n hours may mean ±n*3600 seconds or time with same minutes and seconds values but hours value is changed by n even if a 30 min DST transition happens in between. If agenda interval start falls on skipped time span in local time then the value immediately after transition should be used (and maybe user should be warned by additional entry). For agenda end interval vice versa local time immediately before transition is more suitable. `parse-time-string' has another set of problems. It is impossible to specify particular format like for strptime(3). Actually parsing a string to numerical values and resolving ambiguities in numerical values are different tasks and it may be useful to have separate functions for them. I am unsure however concerning implementing constraints to parse free-form dates. `encode-time' should only accept time zone as time offset and should not allow default or named value that may be ambiguous. If we're talking about Org's encode-time substitute, you can of course do what you like. But Emacs encode-time has supported ambiguous timestamps for some time and I expect it's used by apps that don't care how ambiguous decoded times are resolved, which means we shouldn't remove that support without having a very good reason. There is no reason to impose such restrictions for helpers in Org since Org relies on resolving ambiguities with minimal efforts. `encode-time' supports just one kind of ambiguities. Even though it is the most common one, it is rather (partially false) impression than real support. The truth is that most of developers are not aware of real complexity of dealing with time. Documentation rarely describes limitations and corner cases that should be handled. Even when correct time handling gets more priority i
[BUG] Documentation errata [9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/share/emacs/28.1/lisp/org/)]
Hi all,
this is not actually a bug regarding the code, but the documentation. In
the Manual, when talking about CDLaTeX mode (specifically at
https://orgmode.org/manual/CDLaTeX-mode.html), it is said, regarding the
single quote:
> Pressing the single-quote followed by another character modifies the
symbol before point with an accent or a font.
However, in my setup it's the other way around: first you digit a
character, and THEN you press the single quote. This is also reflected, for
what I saw, in the docstring of the function cdlatex-math-modify, which
says "Modify PREVIOUS char/group/macro with math accent/style." (my
emphasis).
I think this is a typo to be corrected in the Manual. Is this the right
place to make such a suggestion?
Thanks in advance to all and I apologize if this is not the right way to
submit an errata.
I post my configuration after my message.
Alessandro Bertulli
Emacs : GNU Emacs 28.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.33, cairo version 1.17.6)
of 2022-04-09
Package: Org mode version 9.5.2 (release_9.5.2-25-gaf6f12 @
/usr/share/emacs/28.1/lisp/org/)
current state:
==
(setq
org-link-elisp-confirm-function 'yes-or-no-p
org-bibtex-headline-format-function #[257 "\300 \236A\207" [:title] 3
"\n\n(fn ENTRY)"]
org-export-with-sub-superscripts '{}
org-agenda-files '("~/agenda.org")
org-capture-templates '(("c" "Comment" entry
(file+headline "~/.notes" "Comments")
"** Comment %t\n From: %a\n \"%i\"\n\n %?\n\n")
("f" "Fantasy Chronicles" entry
(file+headline "~/FantasyChronicles/notes.org"
"Note rapide")
"** Capture %t\n Da: %a\n \"%i\"\n\n %?\n\n")
("n" "Note" entry (file+headline "~/.notes" "Notes")
"** Note %t\n %?\n\n")
("N" "Titled note" entry
(file+headline "~/.notes" "Notes") "** %? %t\n \n")
("t" "Task" entry (file+headline "~/.notes" "Tasks")
"* TODO %?\n %i\n %a")
("a" "Agenda task" entry
(file+headline "~/agenda.org" "Agenda tasks")
"* TODO %?\n %i\n %a")
)
org-export-before-parsing-hook '(org-attach-expand-links)
org-archive-hook '(org-attach-archive-delete-maybe)
org-odt-format-inlinetask-function
'org-odt-format-inlinetask-default-function
org-ascii-format-drawer-function #[771 " \207" [] 4 "\n\n(fn NAME CONTENTS
WIDTH)"]
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-mode-hook '(#[0 "\301\211 \207"
[imenu-create-index-function org-imenu-get-tree] 2]
visual-line-mode
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-show-all append local]
5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-babel-show-result-all
append local]
5]
org-babel-result-hide-spec org-babel-hide-all-hashes)
org-highlight-links '(bracket plain radio tag date footnote)
org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
org-latex-format-headline-function
'org-latex-format-headline-default-function
org-confirm-shell-link-function 'yes-or-no-p
org-html-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
outline-isearch-open-invisible-function 'outline-isearch-open-invisible
org-use-sub-superscripts '{}
org-odt-format-headline-function 'org-odt-format-headline-default-function
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-confirm-elisp-link-function 'yes-or-no-p
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-html-format-inlinetask-function
'org-html-format-inlinetask-default-function
org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
org-odt-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
org-latex-format-inlinetask-function
'org-latex-format-inlinetask-default-function
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-link-shell-confirm-function 'yes-or-no-p
org-babel-pre-tangle-hook '(save-buffer)
org-agenda-loop-over-headlines-in-active-region nil
org-occur-hook '(org-first-headline-recenter)
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link)
("id" :follow org-id-open)
("eww" :follow org-eww-open :store org-eww-store-link)
("rmail" :follow org-rmail-open :store
org-rmail-store-link)
("mhe" :follow org-mhe-open :store org-mhe-store-link)
("irc" :follow org-irc-visit :store org-irc-store-link
:export org-irc-export)
("info" :follow org-info-open :export org-info-export
:store org-info-store-link)
("gnus" :follow org-gnus-open :store org-gnus-store-link)
("docview" :follow org-docview-open :export
org-docview-export :store org-docview-store-link)
("bibtex" :follow org-bibtex-open :store
org-bibtex-store-link)
("bbdb" :follow org-bbdb-open :ex
