From: Ihor Radchenko <yantar92@posteo.net>
To: Jean Louis <bugs@gnu.support>
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: Wed, 08 Feb 2023 10:36:21 +0000 [thread overview]
Message-ID: <877cwse95m.fsf@localhost> (raw)
In-Reply-To: <Y+LObFnkSdK2UX75@protected.localdomain>
Jean Louis <bugs@gnu.support> writes:
>> It means "when I scheduled this item, I expected the UTC offset at the
>> time of the timestamp to be -08 and remain so. It was motivated by
>> America/Vancouver time zone, but if it changes in future, I do not care
>> - the scheduled time should remain at specific time point relative to
>> UTC".
>
> I read, though sorry, I do not understand who is expected to think
> that UTC offset is fixed?
>
> Is it Org as program?
>
> Or is it human?
Both.
The idea is to ensure exact point of time relative to UTC.
For example, when you want to schedule something exactly 10024 hours in
future, regardless of time zone changes.
The same can be done by specifying the timestamp in UTC directly.
> Another program in future, and human, must know did the organizer of
> event, had in mind:
I would like to remind you that timestamps are not necessarily used for
meetings. And not always shared with other people.
> I find such situations rather easy to solve with database:
>
> - I can have column like "timestamp" with UTC time or local time plus
> UTC offset, and if I did not enter any other information, that UTC
> offset is considered in future. Consider this column name
> "timestamp".
>
> - I can have column "time" and when such is entered, then date is
> extracted from "timestamp" column, and combined with time. In this
> case UTC is only calculated in new time point but not used as period
> from past to appointment time.
>
> - I can have time zone for the future, if I enter such in other
> column, the future calculation must use that proper time zone.
Sorry, I do not understand what you are trying to explain here. Would
you mind showing an example?
> You said "I do not care", that means you as human decide that
> [2024-02-04 12:00 @-08,America/Vancouver] will use fixed -8 offset
>
> But from where in such timestamp does user or program understand that?
From syntax we are now defining, XX takes priority in @XX,YY.
> Maybe this way (hypothetically):
>
> [2024-02-04 12:00 @-08, America/Vancouver/UTC-FIXED]
>
> as that way you would give signal to program that you want UTC fixed
> time in future, and not 12:00 o'clock necessary.
I am sorry, but I don't understand what you mean by UTC-FIXED.
>> > The UTC offset is the log what was the UTC offset at the time point
>> > when timestamp was created, as future UTC offset cannot be known.
>>
>> Sure. -08 is expected offset.
>
> If you wish to specify UTC time in future, no need to specify even any
> offset, but you can.
>
> Look here in first example how event is defined by using UTC time:
> https://icalendar.org/iCalendar-RFC-5545/4-icalendar-object-examples.html
It is sometimes easier to define UTC time +offset instead of doing an
extra conversion in your head.
>> > Making it "fixed" does not fix it in real time, you are then
>> > introducing something new than what other programs do with time.
>>
>> I do not understand this statement.
>
> Well to understand that, you have to make practical examples and
> understand what would human think in periods of time A, B, C, D, from
> creation of appointment, through possible changes of DST, time zone,
> UTC offset, to final appointment.
>
> Look here the second example of group-scheduled meeting that begins at
> 8:30 AM EST on March 12, 1998 and ends at 9:30 AM EST on March 12,
> 1998
> https://icalendar.org/iCalendar-RFC-5545/4-icalendar-object-examples.html
>
> DTSTART;TZID=America/New_York:19980312T083000
> DTEND;TZID=America/New_York:19980312T093000
> LOCATION:1CP Conference Room 4350
> The stuff with iCalendar works for reason that it is structured. The
> timestamp such as: DTSTART:19960918T143000Z will clearly say that time
> is specified in UTC time. No need for confusion with time zone.
> But if DTSTART has this: TZID=America/New_York:19980312T083000
>
> Then it becomes clear that it will be the UTC offset in future with
> assumed mentiond time zone.
>
> But if you mix UTC offset, plus the time zone for future, that makes
> little sense, unless you introduce some tags that timestamp is
> recognizable as using UTC time, or that it uses date/time and time
The problem being addressed with @+08,!Asia/Singapore is possible future
change in time zone. Imagine a yearly meeting you attend at
[2024-01-02 19:00 @Asia/Singapore,!+08] while living in Europe/Athens
(UTC +2). Over the years, you are used to meeting being held 13:00
@Europe/Athens time, and you do not really follow Singapore government
politics on time zones. Then, one year Singapore government decides to
switch the time zone to UTC+7. Your TZDB will get updated, but you may
still miss the meeting even though Org agenda will display the correct
new local meeting time of 14:00 @Europe/Athens. It would be useful if
Org could notify the users about such changes.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
next prev parent reply other threads:[~2023-02-08 10:36 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 [this message]
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
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=877cwse95m.fsf@localhost \
--to=yantar92@posteo.net \
--cc=bugs@gnu.support \
--cc=emacs-orgmode@gnu.org \
--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).