Tom Gillespie <tgb...@gmail.com> writes:
>> Getting the rules and explanation clear is the issue. It's a mistake >> that a great many people make with scheduling meetings. Those two >> behaviors need different encodings because they behave differently. > > This is related to why I suggested splitting timezones and offsets into > two separate categories. I think we have to assume that the written > content of timestamps in an org file cannot/will-not be changed > automatically. > The solution that we used in an operational scheduling system was to invent a new family of time zones, the "Then Local Time There". So you would schedule something like "10:05 TLT (NorthAmerica/New York)". This was the most commonly used scheduled time. It's what most people mean when they schedule something. Then the scheduled time encoding did not change, but the displayed time could. It was displayed in a format that met the needs of the users. When you're dealing with people in many locations you need to separate the concept of scheduled time in the org file from the concept of time display in a format useful to the user. Those who wanted astronomical or other relationships would usually specify UTC or TAI. They might use a fixed offset for UTC. People who are into the demands of TAI (e.g., orbital mechanics) generally don't want to deal with the offsets or other issues that come up with UTC, so they wanted TAI. -- Robert Horn rjh...@alum.mit.edu