From: Jean Louis <bugs@gnu.support>
To: ypuntot <ypuntot@gmail.com>
Cc: 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: Sat, 4 Feb 2023 22:45:33 +0300 [thread overview]
Message-ID: <Y9613aFNHwpEfrLu@protected.localdomain> (raw)
In-Reply-To: <724af979-3825-4818-bc3b-76649752a004@gmail.com>
* ypuntot <ypuntot@gmail.com> [2023-02-04 22:01]:
> Great link!
> https://spin.atomicobject.com/2016/07/06/time-zones-offsets/
>
> "Given a local time and an offset, you can know UTC time, but you do
> not know which time zone you’re in (because multiple timezones have
> the same offset)."
Exactly.
> So, given a time zone you can know the offset (Google it, for
> example).. Then, given the time zone and the local time, you can
> know UTC. If orgmode gets the UTC there is not ambiguity.
Majority of people do not use UTC. Having time displayed in UTC would
and will confuse too many people, unless such time is only for logging
purposes. But Org timestamps like DEADLINE, SCHEDULE, are really meant
for a human.
Internally, in calculations, program shoulde find time time zone, UTC
offset, calculate, go to UTC, again to time zone, and again represent
proper time. And if not that way, in any case there is complexity
involved.
Here is also good reference telling people how to program and work
with time zones.
Working with Time Zones:
https://www.w3.org/TR/timezone/
> But, that would mean that the offset related to the different time
> zones must be downloaded and updated from some site.
For past timestamsp, one could store such as UTC time, and such time
may be easily represented in presen time, it may be viewable in local
time if computer program consults the time zone database.
For timestamps we are making now, to record something, when it
happened, we could use UTC time, but only for logs and similar, not
so important time representations, which we will not revisit too often
in future.
But let us say for some future, timestamps in DEADLINE, SCHEDULED,
those timestamps related to human, the UTC offset in this case cannot
be so sure, because it is in the future, and it is vague as it could
change politically. So the future will know what will be the UTC
offset.
> As you said before, that offset can change. For example, peninsular
> Spain has the same time as Berlin, but as this doesn't make much
> sense, it could change, so updates would be necessary.
That is right.
Even the time zone designation (name) could change in future, but for that
reason, if we use today a time zone, the future time zone database
will know about time zone that (was) defined today, and computer
program will know how to calculate representation of the time in local
time in future, for the time of today.
Time zones are updated regularly, but we cannot be sure of it in case
of atomic war or other planetary commotions. ☹️ I wish people could
love each other more. ☮️
--
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-02-05 8:30 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-04 18:59 [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda) ypuntot
2023-02-04 19:45 ` Jean Louis [this message]
2023-02-05 17:04 ` Max Nikulin
2023-02-07 21:46 ` Jean Louis
-- strict thread matches above, loose matches on Subject: below --
2023-02-12 13:27 Ypo
2023-02-04 21:38 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
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
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=Y9613aFNHwpEfrLu@protected.localdomain \
--to=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).