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

[Jean Louis <bugs@gnu.support>]

* Tim Cross <theophilusx@gmail.com> [2023-01-28 00:15]:
> >
> >> What kinds of representations would a calendar system capable of
> >> handling timezones require?
> >> 
> >> • Instant (fixed)
> >>   • This is referring to an unambiguous moment in time
> >>   • e.g., 2007-02-03T05:00:00.000Z
> >> • Offset (fixed)
> >>   • This captures the idea of "when did it happen for the person who
> >>     made the observation"
> >>   • e.g., 2007-02-03T04:00:00.000+01:00
> >
> > Offset is not that fixed, maybe from viewpoint of storage as maybe it
> > is considered fixed in it's representation, but you have to keep in
> > mind that time offset by it's definition is changing itself, suddenly,
> > depending of daylight saving and time zone.
> >
> 
> I think your misinterpreting the intent here. If you specify a timestamp
> with offset, it is fixed.

That is what you say. And I am pointing out to international standard
references.

If you use offset as "fixed" it means such use would not be by
standard, and you would confusing users and programmers who are using
standard for calculations in programs.

> It does not change with daylight savings or any other change in
> rules for a time zone. It does not even specify a time zone.

And while and before making that decision, did you review the standard
that time zone offset is influenced and changed by daylight savings?

It does not specify time zone. But it is derived from time zone, and
is not same from time zone.

Are you aware that time zone offset could have "skipped time" or
"added time" due to daylight savings?

That implies that by using time offset, you would forget daylight
savings which are international standard, and make calculations wrong,
because you started applying own standard in Org.

Time offset does not independently exists without time zone. While you
represent it without time zone, you have to observe time zone first,
before deriving time offset from it.

Read from:
https://en.wikipedia.org/wiki/UTC_offset

,----
| Daylight saving time
| 
| Several regions of the world use daylight saving time (DST) and the
| UTC offset during this season is typically obtained by adding one hour
| to local standard time. Central European Time UTC+01:00 is replaced by
| Central European Summer Time UTC+02:00, and Pacific Standard Time
| UTC−08:00 is replaced by Pacific Daylight Time UTC−07:00.
`----

Maybe you wish to include a new type of time representation, something
like "Org time offset", in that case you are involving Org developers
into even deeper problems, as then with the new type, you are left all
alone to make that thing work. 

That new type of "fixed" time offset, would not be standard, and would
confuse careful users and programmers.

Example:

- time offset would be PST UTC-08:00, for example 12:00 o'clock

- with daylight saving time event (the time when people switch
  clocks), the offset of PST UTC-08:00, would suddenly become
  UTC-07:00, and the time offset would suddenly become 11:00 o'clock
  in that moment

- now is your decision if you will keep counting 12 o'clock in Org,
  thus creating new type of time specific to Org or 11 o'clock as that
  is the international standard.

Time offset will change with daylight savings, and must be thus
derived from time zone.

> While it is true that a specific location may have time zone changes
> or that the offset from UTC might change as a result of daylight
> savings, an offset specified in a times stamp does not change and is
> fixed.  This is one of the limitaiton with using offset.

It is fixed only if you think is fixed when it is written once, and
then you think it is fixed. 

In the sense of calculation of time, it is not fixed and for any
calculation of time offset you need to observe in which time zone is
that time offset, and if you do not know time zone you can't calculate
it correctly.

Please read Wikipedia article explaining it clearly. 

Please read how in China time offset is not every 15 degrees, and how
there is wording "Although nominally" and "every 15 degrees".

Time offset is thus calculated based on time zone and other factors.

It is derived. 

It is not basic time type to be used for other calculations!

It is a difference of time that is mostly in this way, but shaped by
politics in other way.

Time zone is time added or deducted from UTC. But not just added in
mathematical sense, it is added by considering daylight savings, and
time zones and politics.

> I also think it is a mistake (which I've seen others suggest in this
> thread) to equate an offset as being an abbreviation for a time
> zone. 

That is very right. Time offset may be derived from time zone by using
tz database, but it cannot just be automatically derived.

Time offset is not derived from UTC, it is however, derived from tz
database, observing time zones, politics.

> For example, some have suggested things like +10000 being the same
> as AEST and both being abbreviations for Australia/Sydney outside of
> daylight savings periods. I think that is incorrect.

Using time offset for calculations is useless as it lacks the time
zone, and is only one way of representation for those people who do
not understand time zone.

However, time offset is NOT fixed, it is representation based on time
zone, politics, tz database.

Please read carefully here:
https://en.wikipedia.org/wiki/Daylight_saving_time

and search for time offset to find references.

> +1000 is a fixed offset from UTC

To say that it is fixed you will confuse people here. 

When you say "fixed" you must say in which context it has been fixed.

I have given you enough examples in this e-mail to understand that
time offset in the context of programming is not fixed, as programmer
would need to know the time zone, and time offset may be in different
time zones same! 

Thus deriving time zone unambiguously from time offset is not
possible. You could derive some time zones, but not all. In this
context is not fixed.

Deriving UTC time from time offset by using time offset time stamp IS
possible. In that context it is "fixed".

Deriving positive or negative time difference from time offset is not
unambiguously workable! (Unless you make Org new type of time) This is
not workable because time offset does change with daylight saving time
and also by politics. And to know how it change, again you will need
time zone. In this context it is NOT fixed.

Another good reference:
https://dba.stackexchange.com/questions/94841/how-to-check-the-timezone-for-a-given-datetime

Where the main Answer says: 

,----
| a DATETIME value and a Timezone (name) then you can determine the
| Offset by looking up what the Offset was at that point in time (see
| below for sources of such data)
`----

,----
| The "offset" is a property of the timezone, but it does not, and
| cannot, determine the timezone since:
| 
|    - several timezones can share the same offset
|    - timezones can come and go and can even shift their offset
|    - different regions can change their timezones
`----

And then this following, well expressed answer:

,----
| With only the Offset, the DATETIME value can be converted to UTC, but
| not to another Offset without first having a Timezone database and
| knowing which specific Timezone you are converting it to, which will
| indicate the Offset for that particular point in time
`----

Another problem is that several online explanations on Stack-what are
not giving proper explanation. Please be careful when you go searching
various programmers statements on Stack-what websites, as programmer
may make wrong functions in this or that programming language,
thinking:

"Oh, that ain't workin', that's the way you do it"

Conclusion:
-----------

Time offset is offset to/from UTC time, derived from time zone, and is
only fixed for that specific time point. It cannot be used to derive
other offset, or for programming calculations without using time zone.

Time offset is only a different representation of time.

If it is valid representation depends who and how calculated it. But
let us assume good program did so.

When it is properly represented, it cannot be used as "fixed" time to
calculate differences in time as it lacks time zone information, and
because time offset is changing due to daylight savings and political
decisions. 

-- 
Jean

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

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