"Thomas S. Dye" <tsd@tsdye.online> writes: > Aloha Tim, > > Tim Cross <theophil...@gmail.com> writes: > >> "Thomas S. Dye" <tsd@tsdye.online> writes: >> >>> Aloha Tim, >>> >>>> UTC is a time zone - just one where offset is +0000 >>> >>> UTC is absolute time. It lacks the spatial component that defines a time >>> zone. >>> >> >> Really? I would have thought the prime meridian was the spacial >> component for UTC? I thought the full long time zone name was Etc/UTC >> and UTC as the abbreviation. >> >> Regardless, in all the libraries I've used, you can use Etc/UTC or UTC >> in exactly the same way you would use something like Australia/Sydney or >> AEST. So perhaps, from a pedantic standpoint, it is not a time zone, but >> for all intent and purpose in this discussion, I feel that point is >> irrelevant. > > Agreed. It does seem irrelevant for time zone libraries. > > Nevertheless, from the Org perspective it might not be. An occurrence, which > marks > changes in the nature or relations of things at a time, requires absolute > time. Meetings, > which involve a change in relation among participants, are occurrences. IMO, > this > indicates Org should give occurrences a UTC timestamp, then translate that > for each of the > participants using their local time zone. The insane interval problems that > Ihor brought > up are moot in absolute time. A single timestamp serves a meeting regardless > of whether > the participants are all in one time zone or spread around the globe. > > An occurrence contrasts with an event, which is tied to the user's > space/time. Time here > is relative to the user. IMO, this means that Org should give events a > timestamp without > reference to either absolute time or a particular time zone, like the one it > uses now. >
Just checking if I understand. I think we are coming from the same position and with the same conclusion. In the situation where the meeting involves people from different time zones, the time of the meeting as reported by org needs to be adjusted after a daylight savings transition so that the time maintains the same relative to UTC. i.e. meeting time reported in local time goes forward/backward 1 hour depending on the daylight savings transition (in/out). I guess this is what you call an occurrence? When all participants in a meeting are in the same time zone, you do not want the time changed as the result of the daylight savings transition. This is what you call an event? So, using your terminology, what we now need is convenience functions for setting an occurrence timestamp and an event timestamp. I'm not sure if occurrence/event are the best terms, but I cannot think of better ones. Just slightly concerned people will have trouble grasping the difference and undersanding why some meetings are an occurrence while others are an event. FOr the user, they are just meetings.
