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

[Jean Louis]

* Tim Cross <theophilusx@gmail.com> [2023-01-19 10:48]:
> You completely misunderstood the specific issue being discussed. You
> clearly have not been following this specific point being discussed and
> your long reply just confuses matters rather than helps.
> 
> This issue is in dealing with the meeting time when the local timezone
> changes due to daylight savings time and the fact you have two different
> requirements

I do not use Org for time stamps. I am using PostgreSQL. My time
stamps show correctly (hopefully) as I rely on the design of that
software. I may be very wrong. Though as user I want simple thing, to
record time, and that time has to be displayed in my time zone, and I
want to have functions which will provide for example accounting
statement in the time zone of the recipient in Washington, USA. As
simple as that.

There is no need for Org to deal with daylight savings, as UTC
underlying functions are expected to deal with it. Time zone database,
C library, I cannot know. But any error there shall go to system
maker. Developing such complexity on Org level is not necessary.

For Emacs it makes fun to have various calendars, but for
international time, that has to be handled by system libraries.

> 1. For meeting where all people are in the same timezone, a transition
> in/out of daylight savings changes nothing. The meeting time stays the same
> 
> 2. For meetings wiht people from different time zones, when daylight
> savings transition occurs, the timestamp needs to be changed.  Nothing
> needs to happen for the people in other time zones - it isn't their
> problem and their meeting time is not affected.

Sure, but that is not calculation for higher level like Org, it is for
lower level, like system library. Discussion shall be given to
developers of GNU C library to solve calculations with daylight
savings. If such functions do not exist, then they can be made.

> Ihor['s suggested solution was to just use the TZ of the 'meeting', but
> that is ambiguous. A meeting doesn't have a time zone and picking just
> one of the recipients doens't help as now you just have the issues of
> their daylight savings transitions etc.

☺️ A meeting can have time zone. My friend, that is exactly how we do
meetings, I have even given examples from my life on meeting
scheduling on this mailing list. 

We say "Greek time 9 o'clock AM" -- and we meet and talk to each
other. If there is any daylight saving, so? My computer will think
about it. Not me. I have alarm that counts down, I must rely on my
devices. 

See:

System time and hardware clock
https://www.suse.com/support/kb/doc/?id=000016358

> The Linux kernel maintains a system time. This time is initialized at boot 
> time using the hardware clock(also known as real time clock, RTC, BIOS clock 
> or CMOS clock). As the hardware clock does not provide information as to 
> whether it is kept in UTC or in local time, this needs to be configured 
> explicitly, in YaST -> System -> /etc/sysconfig Editor -> System -> 
> Environment -> Clock -> HWCLOCK.

> Linux changing to and from DST

> Linux will change to and from DST when the HWCLOCK setting is set to `-u', 
> i.e. when the hardware clock is set to UTC (which is closely related to GMT), 
> regardless of whether Linux was running at the time DST is entered or left.

> When the HWCLOCK setting is set to `--localtime', Linux will not
> adjust the time, operating under the assumption that your system may
> be a dual boot system at that time and that the other OS takes care of
> the DST switch. If that was not the case, the DST change needs to be
> made manually.

As you can see it is up to system libraries and user settings how to
provide DST. 

Org need not touch that, only convert from time zone time to UTC, from
UTC to time zone time.

> The 'solution' is to record this meeting in UTC tz. However, to make
> this 'workable' for most people, the interface for managing timestamps
> needs to make this easy.

Then again you have to tell that it is "UTC", which means you are
already specifying some time zone. 

You could tell that Org always thinks of UTC, but that again means UTC
as mark, must be somewhere placed, all users must know that it is UTC,
and again there is need for users to display time in their time zone.

What do you achieve by that design? 

You will get confusion, as you are forcing majority of the world first
to understand what is UTC.

Computers don't do that, they ask you, where are you? Athens, Greece?
Thanks, here is your time.

They don't tell you "let us keep meeting time in UTC" confusing users.

Follow the decade long trend human usability trend and use time zones.

> For example, I would probablyh want an interface where by default,
> my timestamps have no TZ data, but if I call the command to add a
> timestamp with the universal argument, it will add a default tz and
> allow me to easily change it to a different one.

Time stamp does not need to have TZ data, and your function desire is
just fine and correct.

Org file need not have any property of TZ data. 

What needs property is only when:

- Org files is shared or exported so that people in other time zones
  use that

- When single heading as task is shared or some text with embedded
  time stamps

- When user like you change time zone and that change is detected by
  computer (Org)

Which implies that ALL Org exports ever were ambigously created on
export! As in HTML export for example:

Created: 2023-01-19 Thu 17:31 (without time zone) is very ambigous.

-- 
Jean

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

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