From: Jean Louis <bugs@gnu.support>
To: Ihor Radchenko <yantar92@posteo.net>
Cc: Ypo <ypuntot@gmail.com>, Org-mode <emacs-orgmode@gnu.org>
Subject: Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
Date: Fri, 10 Mar 2023 04:37:38 +0300 [thread overview]
Message-ID: <ZAqJ4n+qPmkG1Jpg@protected.localdomain> (raw)
In-Reply-To: <87fsafe5g0.fsf@localhost>
* Ihor Radchenko <yantar92@posteo.net> [2023-03-08 16:29]:
> > The UTC offset is property of the time zone. The future time zone
> > definition will know what is it's UTC offset.
>
> UTC offset is indeed a property of the time zone.
> However, UTC offset may be a subject of change in some time zones.
Yes, and that is what I was stating. What we were arguing about is
rather notation.
> I am referring to "fixed" offsets to be specified by users and will
> never change.
"Fixed" offset is IMHO wrong designation. What you want to say is "UTC
time". Don't use any offsets with UTC time as not to confuse
people. Use local time representation of UTC timestamps. For UTC
timestamp there is no problem to be in future or in past.
> These offsets are convenient to protect timestamp from regulatory
> changes in time zones.
UTC time is convenient.
But if you intend to represent time with time stamps, fixing some "UTC
offsets" to get "UTC time" representation, I do not see how it is
convenient for anybody.
> Effectively, they are simply another, sometimes convenient, way to
> represent UTC time.
Just use UTC time to tell what "fixed" time, and do not use "UTC
offsets" as they are by convention changeable.
> Consider that you need to put a timestamp exactly 1 year from now, even
> if time zone rules change. You are in +04 time zone at
> [2023-03-08 14:00 @Asia/Istanbul].
No matter in which time zone I am, one year from now depends on how
year is calculated
If current timestamp at UTC time is:
2023-03-10 01:08:07
then one year from now is:
2024-03-10 01:08:07
> You can write [2024-03-08 11:00 @Z] or you can write
> [2024-03-08 14:00 @+03]. The latter is nothing but former, written
> without a need to mentally convert back to UTC from your current wall
> clock.
I understand and I do not agree to that notation for reason that it is
confusing, but you please do how you wish.
UTC offset is shown to user in many applications depending on user's
time zone, while time that is fixed is static designation.
I would agree to such notation only if UTC time is written in Org
file, but you provide representation of UTC time showing the UTC
offset.
I see now use of providing "UTC time" with "UTC offset" as that is
beyond conventions.
Then we are speaking out of the reality of what people agreed on this
planet, and people agreed not to use any offsets with UTC time. It is
either UTC time without offset or offset zero, or no offset at all.
But of course Org can be the playground to do what one wish and want.
> > You can introduce something new in Org and say "This is fixed UTC
> > offset in time zone @ABC" but that way you are confusing yourself and
> > future programmer and users, as it does not comply to already accepted
> > international standards.
> >
> > iCalendar proposes different way of representation of time in future,haw
> > that is, it could be UTC time in future, or it could be date, time and
> > time zone. Using UTC offset for future is redundant, as in present
> > time when you are writing future time stamp, you cannot know the
> > future UTC offset.
>
> iCalendar provides just two options: time zone name and UTC. It is ok
> when the timestamps are written programmatically, but not ok when the
> format should be writable by humans manually. I do not see why we should
> force the users to convert to UTC manually in the above scenario.
While I cannot see the context of the above statement, I have never
had any idea of letting user convert some timestamps manually, that is
why computers are there to provide timestamps. I don't do that manually.
> >> icalendar is _not_ the only time spec around. We can take it into
> >> account, but I do not see any reason to follow it blindly.
> >
> > How about finding reasons why iCalendar specifies it that way?
> >
> > And then deciding if those reasons, not specification literally,
> > should be followed?
>
> Feel free to share the underlying logic if you are aware about it.
Which indicates you did not do the homework.
> >> > 4. Hypothetical example of clear timestamp for future:
> >> > [2024-02-04 12:00! @-08,America/Vancouver]
> >> > where the time would be stamped with "!" and that would mean that in the time zone, meeting is at 12 o'clock.
> >> > It would assume that UTC offset can change in future, but 12:00 clock would be authoritative time for future.
> >>
> >> This is ambiguous. 12:00 which time zone? GTM+08? America/Vancouver?
> >
> > The sign "!" is telling "use time, not offset as authoritative". I do
> > not say you should implement it this way, but I am saying it is wrong
> > putting both the time and offset for future time, while you will not
> > know the future offset with certainty.
>
> Ok. I see the problem you referred to. We should then better stick to
> the TEC's proposal here:
>
> ┌────
> │ [2022-11-12 12:00 @+07,Asia/Singapore] # warn when mismatch
> │ [2022-11-12 12:00 @+07,!Asia/Singapore] # use Asia/Singapore over +07
> │ [2022-11-12 12:00 @!+07,Asia/Singapore] # use +07 over Asia/Singapore
> └────
In the above examples there is really nothing to be "warned". When you
give wrong examples for other context, it means you did not understand
it.
You are showing time in past. For time in past, UTC offset is property
of time zone, it is very good to show it, though computer program
could derive it from time zone database, but there is nothing expected
to change in future for such timestamps from past. There is nothing to
be warned, and the time zone MUST match the UTC offset.
Wrong example for the mentioned use case.
We spoke of time designation in future. Not time in past.
Here are comments on time in future:
┌────
│ [2032-11-12 12:00 @+07,Asia/Singapore] # warn when mismatch
Mismatch what? UTC prefix can become +08 in Asia/Singapore zone,
intended time of meeting is 12 o'clock, there is nothing to warn. For
people in that time zone it will be, in case of UTC offset change,
always same 12 o'clock.
If you wish to use some UTC time, as fixed point of time in future,
then use UTC time, do not use time zones.
There is no need to use UTC offset from today in time designation in
future.
And it is not "timestamp" by main definition, as "timestamp" is used
wrongly in Org for future, while timestamp in computing is used for
log files, for past, and is much more definite than how we use it in
present time.
Author of Org was in his own world, without inspecting all these
issues related to time, found somewhere the word "timestamp" and
started using it for planning.
See: https://en.wikipedia.org/wiki/Timestamp
"A timestamp is a sequence of characters or encoded information
identifying when a certain event occurred, usually giving date and
time of day, sometimes accurate to a small fraction of a second."
"Occurred" does not mean "to occure in future".
│ [2032-11-12 12:00 @+07,!Asia/Singapore] # use Asia/Singapore over +07
If you wish to specify time with offset from UTC time, then do not use
time zones. However, that is not common notation.
If you use time zones, computer always need to verify that new, in new
time in future UTC offset, as it could change from the time of writing
it to the time of viewing it.
│ [2032-11-12 12:00 @!+07,Asia/Singapore] # use +07 over Asia/Singapore
└────
If you are to use +07 as offset in future, do not use time zone, as
that is confusing, not common, capricious, and only you claim it is
"convenient". It is hypothetical talk of no use.
> The first timestamp is an error when time zone rules change.
It is not, for reason that your timestamp examples were not relevant
to discussion, as they are from past. Timestamps are in general always
past.
Remove wrong use of the word "timestamp" from Org manual.
Timestamps as you have shown them here below would be perfectly valid,
would you use the proper UTC offset for Asia/Singapore time zone, but
you have not, you used wrong UTC offset of +07 while Asia/Singapore is
+08 time zone.
> ┌────
> │ [2022-11-12 12:00 @+07,Asia/Singapore] # warn when mismatch
> │ [2022-11-12 12:00 @+07,!Asia/Singapore] # use Asia/Singapore over +07
> │ [2022-11-12 12:00 @!+07,Asia/Singapore] # use +07 over Asia/Singapore
> └────
Correct timestamps would be:
> ┌────
> │ [2022-11-12 12:00 @+08,Asia/Singapore] # warn when mismatch
> │ [2022-11-12 12:00 @+08,!Asia/Singapore] # use Asia/Singapore over +08
> │ [2022-11-12 12:00 @!+08,Asia/Singapore] # use +08 over Asia/Singapore
> └────
And for those timestamps, there is no warning when mismatch, because
in future, you cannot change the UTC offset for past (rarely). We
already know that +08 was UTC offset for 2022-11-12 and there is
nothing in future to be warned about it, even if UTC offset for
Asia/Singapore would change to +05, that is not relevant, as in the
past UTC offset was +08 and there is nothing to warn about.
And for following:
> │ [2022-11-12 12:00 @+08,!Asia/Singapore] # use Asia/Singapore over +08
It is contradictory that one places "timestamp" which one would change
in future depending of future time zone! That makes no sense, that is
not timestamp anymore. Do your homework.
If the UTC time was 04:00 because UTC offset was +08, then if user
views the above perverted version of a "timestamp" with changed UTC
offset e.g. +09, which could be designated in future in the new
definition of the time zone, then if you use notion "use
Asia/Singapore over +08", that would imply that timestamp in past
changes. It would not be any more 04:00 UTC time, but it would be
03:00 UTC.
And changing past timestamps is contradictory to the reason of using
timestamps.
And for following:
> │ [2022-11-12 12:00 @!+08,Asia/Singapore] # use +08 over Asia/Singapore
> └────
If UTC offset is there, then it is confusing to use "time zone", if
you wish to designate UTC offset, do not use time zone. But using UTC
offset is contradictory to conventions, so best is to use UTC time
without any UTC offset.
But for future time, if you wish to provide some time that differs
from UTC time, then I would say most logical would be to use again UTC
time, plus added markup to designate interval that has to be added or
deducted from that UTC time. But not in the form of "UTC offset" as
UTC time does not have UTC offset by conventions.
I am referring to something like this:
[2022-11-12 04:00 @Z] + '8 hours'
> In the two other timestamps, the complementary time zone is a redundant
> information that does not affect how the timestamp is interpreted and
> simply aids the human eye. Optionally, users could enable extra checking
> with Org warning about inconsistency for the two latter kinds of
> timestamps as well.
I wish you good luck.
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
next prev parent reply other threads:[~2023-03-10 5:46 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-04 21:38 [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda) Ypo
2023-02-05 3:12 ` Max Nikulin
2023-02-05 9:31 ` Jean Louis
2023-02-05 10:44 ` Ihor Radchenko
2023-02-05 12:12 ` Jean Louis
2023-02-05 13:01 ` ypuntot
2023-02-06 14:15 ` Ihor Radchenko
2023-02-07 21:38 ` Jean Louis
2023-02-06 14:10 ` Ihor Radchenko
2023-02-07 22:19 ` Jean Louis
2023-02-08 10:36 ` Ihor Radchenko
2023-02-10 3:29 ` Jean Louis
2023-02-10 10:48 ` Ihor Radchenko
2023-02-12 9:33 ` Jean Louis
2023-02-12 13:47 ` tomas
2023-02-14 6:00 ` Jean Louis
2023-02-14 9:41 ` Heinz Tuechler
2023-02-14 9:45 ` tomas
2023-02-14 11:42 ` Max Nikulin
2023-02-14 15:59 ` Jean Louis
2023-02-14 16:45 ` Thomas S. Dye
2023-02-16 14:21 ` Jean Louis
2023-02-14 16:57 ` Max Nikulin
2023-02-14 10:45 ` Jean Louis
2023-03-10 10:46 ` Ihor Radchenko
2023-03-08 13:30 ` Ihor Radchenko
2023-03-10 1:37 ` Jean Louis [this message]
2023-02-11 4:44 ` Max Nikulin
2023-02-12 10:32 ` Jean Louis
2023-02-15 15:17 ` Ihor Radchenko
2023-02-16 15:06 ` Jean Louis
2023-03-10 10:51 ` Ihor Radchenko
2023-03-15 14:42 ` Max Nikulin
-- strict thread matches above, loose matches on Subject: below --
2023-02-12 13:27 Ypo
2023-02-04 18:59 ypuntot
2023-02-04 19:45 ` Jean Louis
2023-02-05 17:04 ` Max Nikulin
2023-02-07 21:46 ` Jean Louis
2023-01-17 3:55 [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda Daryl Manning
2023-01-17 8:22 ` Tim Cross
2023-01-17 9:15 ` Ihor Radchenko
2023-01-17 9:45 ` Tim Cross
2023-01-18 9:15 ` Ihor Radchenko
2023-01-18 11:43 ` Tim Cross
2023-01-18 12:02 ` Ihor Radchenko
2023-01-18 21:16 ` Tim Cross
2023-01-19 5:29 ` Jean Louis
2023-01-19 7:23 ` Tim Cross
2023-01-19 14:32 ` Jean Louis
2023-01-19 20:09 ` Tim Cross
2023-01-19 23:02 ` Thomas S. Dye
2023-01-19 23:51 ` Tim Cross
2023-01-20 0:24 ` Thomas S. Dye
2023-01-20 3:46 ` Tim Cross
2023-01-20 6:14 ` Thomas S. Dye
2023-01-27 6:06 ` Sterling Hooten
2023-01-27 11:09 ` Ihor Radchenko
2023-01-30 11:25 ` Greg Minshall
2023-01-31 11:48 ` [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda) Ihor Radchenko
2023-01-31 12:19 ` Daryl Manning
2023-01-31 12:41 ` Ihor Radchenko
[not found] ` <CAL9aZksf8AGF=dXg0KAtLPyu1ATt1fLpvdsjN6GMCuK2KRQ56w@mail.gmail.com>
2023-01-31 13:33 ` Ihor Radchenko
2023-01-31 13:22 ` Jean Louis
2023-01-31 13:46 ` Ihor Radchenko
2023-01-31 19:59 ` Jean Louis
2023-02-01 12:42 ` Ihor Radchenko
2023-02-01 15:28 ` Jean Louis
2023-02-01 16:30 ` Ihor Radchenko
2023-01-31 20:12 ` Jean Louis
2023-02-01 5:46 ` tomas
2023-02-01 7:29 ` Jean Louis
2023-02-01 7:52 ` Tim Cross
2023-02-01 8:32 ` Jean Louis
2023-02-01 8:46 ` Ihor Radchenko
2023-02-01 9:38 ` Tim Cross
2023-02-01 10:15 ` Ihor Radchenko
2023-02-01 14:53 ` Jean Louis
2023-02-01 16:36 ` Ihor Radchenko
2023-02-01 10:46 ` Max Nikulin
2023-02-01 14:43 ` Jean Louis
2023-02-01 16:45 ` Ihor Radchenko
2023-02-02 3:05 ` Max Nikulin
2023-02-02 8:59 ` Ihor Radchenko
2023-02-01 14:38 ` Jean Louis
2023-02-01 16:50 ` Ihor Radchenko
2023-02-01 7:00 ` Thomas S. Dye
2023-02-01 7:41 ` Jean Louis
2023-01-31 18:56 ` Greg Minshall
2023-02-01 12:48 ` Ihor Radchenko
2023-02-01 12:52 ` tomas
2023-02-02 4:49 ` Greg Minshall
2023-01-31 20:41 ` Tim Cross
2023-01-31 23:50 ` Samuel Wales
2023-02-01 13:01 ` Ihor Radchenko
2023-02-04 22:33 ` Samuel Wales
2023-02-04 22:49 ` Samuel Wales
2023-02-05 10:38 ` Ihor Radchenko
2023-02-01 11:56 ` Christian Moe
2023-02-01 12:20 ` Ihor Radchenko
2023-02-01 15:41 ` Jean Louis
2023-02-02 8:38 ` Ihor Radchenko
2023-02-03 11:31 ` Jean Louis
2023-02-04 10:58 ` Ihor Radchenko
2023-02-04 19:32 ` Jean Louis
2023-02-05 9:14 ` Ihor Radchenko
2023-02-02 3:46 ` Timothy
2023-02-02 9:12 ` Ihor Radchenko
2023-02-02 9:12 ` Timothy
2023-02-02 9:20 ` Ihor Radchenko
2023-02-02 9:27 ` Timothy
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=ZAqJ4n+qPmkG1Jpg@protected.localdomain \
--to=bugs@gnu.support \
--cc=emacs-orgmode@gnu.org \
--cc=yantar92@posteo.net \
--cc=ypuntot@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/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).