From: Paul Eggert <eggert@cs.ucla.edu>
To: Eli Zaretskii <eliz@gnu.org>
Cc: manikulin@gmail.com, emacs-devel@gnu.org
Subject: Re: Time resolution in Emacs argument optional ones
Date: Fri, 22 Apr 2022 11:22:11 -0700 [thread overview]
Message-ID: <af1c05ed-60f7-a46b-f838-f6ece77631e4@cs.ucla.edu> (raw)
In-Reply-To: <837d7hr8s3.fsf@gnu.org>
On 4/21/22 22:23, Eli Zaretskii wrote:
> There's no problem
> whatsoever to provide high-resolution time stamps on MS-Windows, if we
> decide that this is what we want. The only reason we didn't do that
> until now is that it wasn't deemed important.
An example of when this matters is that GNU 'ls' needs to know whether a
file timestamp is in the future because 'ls -l' uses a different textual
format for future timestamps than it does for recent-past timestamps, as
a visual cue to the user that the user has a clock skew problem that can
screw up GNU 'make' and similar programs. For example, if I run the
shell script:
touch now
touch --date=@$(date +%s.%N | sed 's/........$/99999999/') future
ls -l future now
Here's the output I should see, because 'future' has a timestamp in the
future:
-rw-rw-r--. 1 eggert eggert 0 Apr 22 2022 future
-rw-rw-r--. 1 eggert eggert 0 Apr 22 11:13 now
However, if GNU 'ls' got the time of day with lower resolution than it
got file timestamps, it would use the wrong textual format for a
recently-created file's timestamp, because it would compare a lower-res
time-of-day like 1650651200.73 to a higher-res file timestamp like
1650651200.734627956 that was generated before the current time. The
above example would therefore generate the incorrect output:
-rw-rw-r--. 1 eggert eggert 0 Apr 22 11:13 future
-rw-rw-r--. 1 eggert eggert 0 Apr 22 11:13 now
When Emacs needs to do something like what GNU 'ls' does, it can have
the same issue.
Admittedly this is not the most important issue on Emacs's plate. Still,
Emacs should do a good job and be compatible with other GNU tools.
>> This sort of disagreement is inherent to how timestamp resolution works.
>
> I'm asking why timestamp resolution, as defined by HZ, at all matters
> in Emacs.
It matters for applications like GNU 'ls' as described above. It also
matters for applications that want to display a timestamp accurately,
but without excess information that bogs down performance and implies
more precision than is actually present. For example, current GNU 'date'
can use a format '%s.%-N' that outputs the current time without excess
trailing zeros in the subseconds part. Emacs should be able to do
something similar.
> please provide a list of use cases
> where you can show that using this definition of time resolution is
> important, and not using that would lead to problems.
Doing what GNU 'ls' does, and what GNU 'date' does, are two use cases.
Another example is doing what GNU 'cp -u' does when comparing file
timestamps. I expect there are others.
> An alternative would be to decide on a unified resolution for time
> objects in Emacs, independent on what the underlying system does, and
> then use that everywhere. Why not do that?
We've already done that in Emacs with the (TICKS . HZ) representation.
The obvious fix here would be to use better time-of-day primitives on
Microsoft Windows, in particular, primitives that don't use a syncopated
clock. (By "syncopated clock" I mean one that doesn't beat on 1-second
boundaries.) This would be simpler than adding support for syncopated
clocks to the Emacs timestamp format, as syncopated clocks are too much
trouble to document and implement and would complicated too much code
for too little benefit.
Besides, a precision of only 1/64 second on the time of day is not
adequate for quite a few applications these days, so this issue of
low-resolution time-of-day should be fixed on MS-Windows regardless of
how Emacs represents timestamps internally.
>> > Yes, but file timestamps should use the resolution of the file system,
>> > which in general is different from the resolution of the system clock.
>> > That's a separate matter, which would be the subject of a separate
>> > patch. For now we can stick with what we already have in that department.
>
> Sorry, I don't understand what that "for now" means.
I meant that we can stick with what we currently do for file timestamps,
which is to generate Emacs Lisp timestamps with a greater resolution
than what the file timestamps actually have. This loses information
about the resolution, but does not lose information about the time values.
This doesn't mean I'm a fan of the current situation with file
timestamps. It means only that we can address the current-time problem
in one patchset, and the file timestamp issue in a later patchset. It
will be better to separate the solutions in this way, than to try to
solve the problem all at once.
> It should be part of the discussion.
OK.
next prev parent reply other threads:[~2022-04-22 18:22 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5ed963b2-3fa8-48d8-627e-bc0571d15b43@gmail.com>
[not found] ` <149de00f-115b-5367-414f-c7700ef8966b@cs.ucla.edu>
[not found] ` <c6525aa8-1496-8ebe-cf2a-24f65cc44672@gmail.com>
[not found] ` <2dd15844-01b3-0144-740c-185ec8488a81@cs.ucla.edu>
[not found] ` <4a23f3a4-fe8f-d396-49d8-10034803be63@gmail.com>
[not found] ` <52fb10fb-892a-f273-3be8-28793f27e204@cs.ucla.edu>
[not found] ` <5cd820d4-ae67-43d4-9e63-c284d51ff1e4@gmail.com>
[not found] ` <f9d9d26c-1974-b52a-8f4d-49167676c102@cs.ucla.edu>
[not found] ` <83tuapvcxs.fsf@gnu.org>
[not found] ` <6efc5d24-34a2-fd30-cd20-fe4ac3e48310@cs.ucla.edu>
[not found] ` <83fsm8tdzl.fsf@gnu.org>
[not found] ` <9e4781b2-2ffa-b1ce-09b4-ead82cad9038@cs.ucla.edu>
[not found] ` <83ilr3siku.fsf@gnu.org>
[not found] ` <4e41671c-fae8-61c4-845c-4c7ba4317e88@cs.ucla.edu>
[not found] ` <83fsm7sh2s.fsf@gnu.org>
[not found] ` <e4cc58ca-51f9-395e-05f5-5f06cb9d439d@cs.ucla.edu>
[not found] ` <83czhbsgc2.fsf@gnu.org>
[not found] ` <33fb24fb-282b-cc13-a597-e7b63f19982d@cs.ucla.edu>
[not found] ` <83y1zzq6kd.fsf@gnu.org>
[not found] ` <aa2bc0a0-1bec-37ff-919d-c20fcdfdab68@cs.ucla.edu>
2022-04-22 5:23 ` Time resolution in Emacs argument optional ones Eli Zaretskii
2022-04-22 18:22 ` Paul Eggert [this message]
2022-04-22 18:52 ` Corwin Brust
2022-04-22 21:26 ` Paul Eggert
2022-04-23 6:27 ` Time resolution in Emacs Eli Zaretskii
2022-04-24 0:56 ` Paul Eggert
2022-04-24 6:10 ` Eli Zaretskii
2022-04-24 11:47 ` Max Nikulin
2022-04-24 12:23 ` Eli Zaretskii
2022-04-25 15:32 ` Paul Eggert
2022-04-25 16:01 ` Eli Zaretskii
2022-04-22 19:35 ` Time resolution in Emacs argument optional ones Eli Zaretskii
2022-04-22 21:52 ` Paul Eggert
2022-04-23 6:51 ` Time resolution in Emacs Eli Zaretskii
2022-04-25 15:34 ` Paul Eggert
2022-04-25 16:10 ` Eli Zaretskii
2022-04-25 16:38 ` Paul Eggert
2022-04-25 16:57 ` Eli Zaretskii
2022-04-25 16:54 ` Max Nikulin
2022-04-25 17:02 ` Eli Zaretskii
2022-04-25 19:27 ` Paul Eggert
2022-04-29 15:19 ` Max Nikulin
2022-04-29 16:07 ` Eli Zaretskii
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.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=af1c05ed-60f7-a46b-f838-f6ece77631e4@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=manikulin@gmail.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.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).