Greg Minshall <minsh...@umich.edu> writes:
> Russell, > >> I would not suggest using UTC. I believe one of the reasons timestamps >> didn't include TZ information was to keep them short and human >> legible. Solutions with overlays to change a timestamp reduce the >> usefulness of the plain text reading of Org (ie: less, grep, >> etc). Storing timestamps with UTC is really a shortcut for the >> computer, not the user. > > i wonder if this is perhaps another place where "org mode as simple > text" conflicts with "org mode to solve difficult problems". that comes > up from time to time (using dollar signs as delimiters for math is one > recent example, another is "-" being "filled" into column one and taken > as an item in a new list). > > it's a hard line to straddle. > I think you are correct. There are fairly frequent issues associated with timestamps and much of it is due to the tension between trying to have something which is human friendly and having something which lends itself to being used for calculations or in an environment where the timezone regularly changes (i.e. from someone who travels a lot). Adding timezone infomation to timestamps by default is not difficult. Org uses Emacs' time handling functions under the hood and supports setting custom timestamp formats. If I was someone who regularly moved between timezones, I would definitely modify the default format to ensure timezone information is recorded with the timestamp. This would at least let the user know what timezone was being referenced when the timestamp was created and what needs to be done to (even mentally) convert it to whatever the current timezone is. For any calculations involving timestamps, the only sane way to do things is to convert all timestamps to UTC, perform the calculation and if necessary, convert back to localtime for final result. It was mentioned elsewhere in this thread that issues associated with DST changes are OK because they occur early in the morning and not much happens around then. However, this ignores use cases that depend on calculation of time intervals. Provided all calculations are performed using UTC, everything should work as long as timestamps include TZ info. I don't like the idea of having a header variable which records the timezone. I think this will be a source of errors and confusion and just won't work well for many setups (for example, people like me who have many org files with timestamps in them). I feel a better result would be to - Update default timestamp format to include timezones - Add a new function which would either (or all of) - Convert an existing timestamp to a specified tz - Convert all timestamps in a file to a specific tz - Convert all timestamps in agenda files to a specific tz - Convert all timestamps in all org files to a specific tz User can then run the function as required (for example, after changing timezone location). - Ensure all exporter back ends support the ability to set an export timestamp function, allowing changing/stripping of TZ data during export as you frequently want a more concise format in exported documents. I believe this is already supported to some extent. The other things we could probably add is a timestamp display tooltip/overlay which could be defined to popup when the mouse/cursor is on the timestamp and which would display the timestamp in some timezone which the user could specify as an option and which defaults to whatever the local timezone is at the time. Then, when you see a timestamp which is in lets say US EDT and your in Tokyo, moving your cursor or placing your mouse on that timestamp would display a tooltip showing the local time equivalent. -- Tim Cross
