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
argume
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:
Thanks, I looked at that and have a
On 26/04/2022 02:49, Paul Eggert wrote:
On 4/25/22 08:37, Paul Eggert wrote:
I'll be happy to review the revised org-encode-time implementation,
whenever you think it could use a review. (Sorry, I've lost track of
what the proposal is.)
I suspended my activity due to discussions of other cha
On 4/25/22 08:37, Paul Eggert wrote:
Yes, I plan to omit the patches that were objected to, and install the
rest. Once that's done you should be good to go for Org. (Alas my
workstation died over the weekend, but I should have things up and
running again soon...)
Got my workstation up, instal
Yes, I plan to omit the patches that were objected to, and install the
rest. Once that's done you should be good to go for Org. (Alas my
workstation died over the weekend, but I should have things up and
running again soon...)
On 21/04/2022 01:29, Paul Eggert wrote:
On 4/20/22 08:07, Max Nikulin wrote:
I still believe that optional DST and ZONE values is an improvement of
the `encode-time' interface with no real drawbacks.
Yes, that's the direction we're headed.
Paul, a week has passed since you posted the patch
On 4/20/22 20:19, Paul Eggert wrote:
> diff --git a/lib/gettime-res.c b/lib/gettime-res.c
> index 611f83ad27..bb4d0b191d 100644
> --- a/lib/gettime-res.c
> +++ b/lib/gettime-res.c
> @@ -53,6 +53,8 @@ gettime_res (void)
>
>long int hz = TIMESPEC_HZ;
>long int r = hz * res.tv_sec + res.tv_nse
> Date: Thu, 21 Apr 2022 16:56:25 -0700
> Cc: maniku...@gmail.com, emacs-orgmode@gnu.org, 54...@debbugs.gnu.org,
> bug-gnu...@gnu.org
> From: Paul Eggert
>
> What appears to be happening here is that the MS-Windows native
> timestamp resolution is 1/64th of a second, and your system's clock is
What appears to be happening here is that the MS-Windows native
timestamp resolution is 1/64th of a second, and your system's clock is
offset by 0.0075 s from an integer boundary. I.e., the timestamps in
increasing order are:
...
1650522862 + 62/64 + 0.0075 = 1650522862.976250
1650522862
On 17/04/2022 02:23, Paul Eggert wrote:
On 4/15/22 10:23, Max Nikulin wrote:
if you are storing future events bound to wall time then namely time
zone identifier should have precedence.
Although that would make sense for some applications it's not a good
idea in general. For example, if you'
> Date: Wed, 20 Apr 2022 17:11:34 -0700
> Cc: maniku...@gmail.com, emacs-orgmode@gnu.org, 54...@debbugs.gnu.org,
> bug-gnu...@gnu.org
> From: Paul Eggert
>
> On 4/20/22 12:30, Eli Zaretskii wrote:
>
> > I see the time samples change in jumps of 15 msec.
>
> Could you give the first part of the
On 4/20/22 12:30, Eli Zaretskii wrote:
I see the time samples change in jumps of 15 msec.
Could you give the first part of the output? I would like to see what
the the samples are jumping from and to, and how often they jump.
Something like the following is what I'd hope to see from the fir
On 4/20/22 12:14, Eli Zaretskii wrote:
Sorry, my bad. The result is the same, but I do get printouts. What
do you want to know or see from there?
I want to see what the current_timespec's resolution is, which we should
be able to tell from the debugging output. For example, on my Solaris 10
> Date: Wed, 20 Apr 2022 12:23:43 -0700
> Cc: maniku...@gmail.com, emacs-orgmode@gnu.org, 54...@debbugs.gnu.org,
> bug-gnu...@gnu.org
> From: Paul Eggert
>
> On 4/20/22 12:14, Eli Zaretskii wrote:
> > Sorry, my bad. The result is the same, but I do get printouts. What
> > do you want to know o
On 4/20/22 09:56, Max Nikulin wrote:
A typo: double "a".
Thanks, fixed in the attached which I installed in master.
If I get your idea correctly then "January, 31" + "1 month" should be
more impressive as impossible date.
Thanks, good idea; also in the attached patch.
I can not figure o
> Date: Wed, 20 Apr 2022 11:19:29 -0700
> Cc: maniku...@gmail.com, emacs-orgmode@gnu.org, 54...@debbugs.gnu.org,
> Gnulib bugs
> From: Paul Eggert
>
> > Thanks, the test-gettime-res test says "gettime_res returned 625000
> > ns", which is a strange number: it doesn't fit any MS-Windows system
On 4/20/22 08:07, Max Nikulin wrote:
I have not checked if mktime is a part of
POSIX and C standard.
mktime is part of both the C standard and POSIX. POSIX extends the C
standard by saying that time_t is an integer type (the C standard allows
time_t to be a floating-point type) and that time_t
> Date: Wed, 20 Apr 2022 12:01:27 -0700
> Cc: maniku...@gmail.com, emacs-orgmode@gnu.org, 54...@debbugs.gnu.org,
> bug-gnu...@gnu.org
> From: Paul Eggert
>
> > I get the same result, and moreover I see no differences between this
> > and the previous tarball, and no printouts in test-gettime-res
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/lispr
On 19/04/2022 09:02, Paul Eggert wrote:
Here are the main points I see about making timestamps work better in
Org mode, and related patches to how Emacs handles timestamps.
* Max would like encode-time to treat a list (SS MM HH DD MM ) as if
it were (SS MM HH DD MM nil -1 nil),
Than
> Date: Tue, 19 Apr 2022 15:22:29 -0700
> Cc: maniku...@gmail.com, emacs-orgmode@gnu.org, 54...@debbugs.gnu.org
> From: Paul Eggert
>
> On 4/18/22 22:50, Eli Zaretskii wrote:
> >> * admin/merge-gnulib (GNULIB_MODULES): Add gettime-res.
> >> * lib/gettime-res.c: New file, copied from Gnulib.
> >>
> Date: Mon, 18 Apr 2022 19:02:03 -0700
> From: Paul Eggert
> Cc: emacs-orgmode@gnu.org, 54...@debbugs.gnu.org
>
> From 8c25372709d256d83858be454987137dc202b725 Mon Sep 17 00:00:00 2001
> From: Paul Eggert
> Date: Mon, 18 Apr 2022 13:08:27 -0700
> Subject: [PATCH 3/6] Add Gnulib gettime-res modu
Here are the main points I see about making timestamps work better in
Org mode, and related patches to how Emacs handles timestamps.
* Max would like encode-time to treat a list (SS MM HH DD MM ) as if
it were (SS MM HH DD MM nil -1 nil), as that would be more
convenient for how Org m
On 4/16/22 09:26, Max Nikulin wrote:
Feel free to shorten the added fragment, to change the wording, or to
use your variant instead. See the attachment.
Thanks, I installed that and then installed the attached, which merges
that with some documentation improvements that I drafted based on this
On 4/15/22 10:23, Max Nikulin wrote:
if you are storing future events bound to wall time then namely
time zone identifier should have precedence.
Although that would make sense for some applications it's not a good
idea in general. For example, if you're scheduling a Zoom meeting you
should
On 09/04/2022 14:52, Paul Eggert wrote:
On 4/7/22 05:37, Max Nikulin wrote:
Daylight saving time field matters only as a list component and
ignored as a separate argument (by the way, it should be stressed in
the docstring).
Do you have a wording suggestion? (The doc string already covers th
On 15/04/2022 05:46, Paul Eggert wrote:
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
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
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 202
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, encod
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 unde
On 09/04/2022 14:52, Paul Eggert wrote:
0001-Improve-Org-usage-of-timestamps.patch
From 094345e10ad45e06f7b32e2f8017592210f43463 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sat, 9 Apr 2022 00:17:09 -0700
Subject: [PATCH] Improve Org usage of timestamps
MIME-Version: 1.0
Content-Type: text/
On 09/04/2022 14:52, Paul Eggert wrote:
On 4/7/22 05:37, Max Nikulin wrote:
From my point of view it is better to change implementation of
`encode-time' so that it may accept 6-component list SECOND...YEAR. It
should not add noticeable performance penalty but makes the function
more convenie
I am sorry, I have realized that debbugs.gnu.org does not send copies to
the addresses specified in the X-Debbugs-CC header of the original
report. Now I am sending a copy of my earlier message to emacs-orgmode.
Please, add 54...@debbugs.gnu.org to replies to this message.
Paul,
I am sorry th
On 4/7/22 05:37, Max Nikulin wrote:
(encode-time '(0 30 20 07 04 2022 nil nil nil)) ; wrong!
Yes, and I see a couple of places (org-parse-time-string,
org-read-date-analyze) where Org mode returns the wrong decoded
timestamps, ending in (nil nil nil) even though the DST flag is unknown
Consider the following change of `encode-time' calling convention: last
3 elements of the TIME argument as a list should be optional. I mean
IGNORED, DST, and ZONE.
(encode-time '(0 30 20 07 04 2022 nil -1 nil))
(encode-time '(0 30 20 07 04 2022)) ; currently causes an error
Since Em
36 matches
Mail list logo
