* Thomas S. Dye <tsd@tsdye.online> [2023-01-19 09:37]: > Meetings are occurrences, which require absolute time, which has no > timezones. Org should record occurrences with timestamps in UTC, > possibly translating from the user's local time.
User in Grece needs appointment at 9 o'clock, and writes it as: <2023-01-20 Fri 09:00> He also has TIMEZONE (either system or Org file based) set to "EET". That way the time has been recorded in UTC for Org purposes, and UTC has been solved. For Greek user it is completely solved. Org calculates UTC based on configured time zone. But when it is 16:00 o'clock in Greece, it is 06:00 in Seattle. Online appointment is sent to user in Seattle, with the time zone PST. He receives the Org file from Greece, at 8:00 o'clock, which has settings inside TIMEZONE="EET". At first user thinks that appointment is in just 1 hour, because he can see "08:00", but Org gracefully notifies user that appointment is (probably) in a different time zone, and asks user if user would like to have it displayed in PST time zone. User answers with "Yes" and on his screen appears that meeting is actually at <2023-01-20 Fri 23:00>, he prepares himself for longer evening, and waits for his Greek partner on Jitsi Meet: https://meet.jit.si/ to get online. It confirms your hypothesis, yes, all times are calculated as UTC, but all time stamps at export, sharing, or change of time zone, shall be displayable in understandable manner to human user. > > Org in this state can't handle such things. > > Org can do the useful thing: translate the UTC timestamp into local time and > report both UTC and local time. User will be able quickly to determine if > local time is incorrect for some reason, such as DST or travel. Other way around, it has to translate time stamp into UTC time in the first place. Expecting that all user among so many various time zones write their time stamps in UTC is not reasonable. Org users are advanced, I know, but majority of note takers with other applications will not even think of different time zones, it is surprise they get when dealing internationally. People are not ready for calculating or even viewing their own time in UTC time zone, unless they are English or Icelandic, Portuguese, or Africans in parts of the West Africa. > Storing timestamps in UTC solves the interval problem Ihor > raised. Intervals always make sense in absolute time. Moving them > to event time leads to the insanity Ihor mentioned. The other way around. Assuming that time stamps are UTC raises problems for all other people: https://upload.wikimedia.org/wikipedia/commons/8/88/World_Time_Zones_Map.png Org now does not support time stamps, right? So people write timestamps in their own time zone! Is it right? My time stamp here is <2023-01-19 Thu 17:12> now, what is yours? Forcing users to write time stamps in UTC would cause havoc. Thus time stamps already have their time zones, it is just not recorded in Org file. Options can be created so that: - user always and automatically record time zone in Org file, for example from system time zone, so that when first time property is invoked that it stays there: #+TIMEZONE: EET Or like this * TODO Appointment on Jitsy Meet with Greek investor DEADLINE: <2023-01-20 Fri 09:00> :PROPERTIES: :TIMEZONE: EET :END: or inside of the time zone. When such heading is read in Seattle, Washington, Org will tell to user or ask to translate it to PST time. In such translations, EET time is first converted to UTC, for reason of using system libraries, and not complicating Org, and then converted to PST time zone. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
