emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-ag


From: Jean Louis
Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
Date: Mon, 30 Jan 2023 22:37:51 +0300
User-agent: Mutt/2.2.9+54 (af2080d) (2022-11-21)

Dear Thomas,

I give my best to find references for you and explain you the possible
problem in calculation of time stamps. That problems exist is clear.

To solve problem it is important to first define it. And when there
are developers reading it, I wish to provide best possible references
for the sake of people using Org mode.

So let me gently try explaining it with different words.

> UTC offset exists without time zone.

I have already stated that UTC offset is property of a time
zone. Single time zone may have different UTC offset. 

A time zone must have UTC offset as it's property, as how else would
people know what time is in Berlin/German? Is it by guessing?! So for
that reason on this planet countries agreed politically to define one
or more UTC offset for every time zone.

UTC offset is thus always derived from the time zone. That it "exists
without time zone" is something individual, but when we speak of UTC
offset, we know that it was derived from time zone. 

What we cannot know unambiguously is from which time zone it was
derived.

> UTC is absolute time

As we know absolutes are impossible, especially about representation
of "time", we people have only agreed on how to define UTC time, that
is what we count internationally. Let us assume it is absolute.

> and offsets from it do not refer to political time in a time
> zone.

It is good to observe the map to understand if UTC offset does not
refer to political time or maybe it does?

All time zones have their UTC offsets, as otherwise we would not be
able to calculate time by sole name of city like Berlin, so Berlin
must have defined UTC offset, and all time zones, from which UTC
offsets are derived are politically decided, this includes UTC offset,
which are very much political or in other words they are decided by
people in power or in authority.

> They refer to local *solar time* at a particular place.

They maybe should so, but that type of solar time is also politically
decided, it is not something calculated or really accurately
pinpointed time. You may observe it on the map, and decide if it
really refers to solar time or solar time is politically decided, or
maybe something else?

Solar time is also not much relevant for Org, as what I would like to
see in Org is precision with time calculations.

While I cannot guarantee for accuracy of these maps, it will be
beneficial to look at them and make a practical exercise.

Look at this nice map with time zones and UTC offsets:
https://qz.com/wp-content/uploads/2015/03/map.jpg?quality=80&strip=all&w=3000

I guess that only by looking one can see that it cannot be possibly
accurate "solar time", but we can speak of approximate solar time, as
differences of 1-4 or 5 hours in solar terms is nothing so
special. Anyway, solar time is not important for programming
calculations.

What we wish to observe is not to make mistake in programming by using
UTC offset incorrectly, as IMHO, that alone would be poor choice for
Org developers to stick to it.

Excercises:
-----------

1. Observe that tim zone in Iran has offset of 3.5+ hours, while North
   from Iran at the same Earth longitude in Turkmenistan, there is
   offset of UTC 5+ -- solar time can't be accurate that way.

2. UTC offset depends on time zone, it is the property of time
   zone. See the map to understand.

3. UTC offset may be changed by decisions of authorities and is
   dependant on daylight savings and political changes, as it has to
   be derived from time zone. 

4. By using UTC offset one can find UTC time, like Max say, that is
   for many applications alright, but it will not make it accurate.

   I am reluctant to accept that UTC offset is enough, unless it is
   demonstrated that it will bring the intended purpose in Org.

   As that is just one parameter that is derived from time zone. That
   is not how other applications work, they will either store time in
   UTC, or time with time zone representation including UTC, plus
   including the UTC offset.

   One need time zone to understand and calculate future times for
   people who change time zones, for example in Org Agenda, as by
   using UTC offset only, one would need to first convert it to time
   with time zone of the user viewing that time, and then to UTC
   offset of the user viewing that time representation.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]