shironeko <shiron...@tesaguri.club> writes:
> Hi everyone, > > I, like many others on this list, have to move between timezones quite > frequently. As I gathered from the archive, it seems the main complexity in > supporting timezones is the difficulty revolving the change of timestamp > format. > So I have an idea, suppose we add a new keyword, "TIMEZONE" that can be set at > the start of the file like so > > #+TIMEZONE: America/Toronto > > This specifies the timezone of all timestamps in the file. Together with it, > there can be a function called e.g. org-shift-time, that shifts all the > timestamp in the file to another specified timezone and updates the keyword. > Of > course, care needs to be taken when dealing with dates without time, e.g. it > should be treated as at time 00:00 when it is alone or as the start of a time > range, and be treated as at time 24:00 when it is the end of a time range. > > Then there could be hooks that offer to run the function automatically when it > detects the user's system or emacs is set to a different timezone as in the > file > (e.g. when they open the file, or opens the agenda). This will make sure the > timestamps always aligns with their current one (if they wish). > I'm sorry, but I don't like this idea. In general, I think it is the wrong approach and not sophisticated enough to work with the complexities associated with timestamps. This is actually a very hard problem and not one which can be adequately addressed with something this simple. Problems include 1. Timzone alone is not sufficient. Offsets from UTC change due to daylight savings times etc. 2. You can easily have timestamps from different timezones in the same org file 3. Storing timestamps in local time is problematic because of the inherent ambiguity this can have (again, due to daylight savings times and what occurs at the 'cut over' time). 4. Sometimes, you may want the timestamp to reflect the date/time as it was when recorded and don't want it to 'change' because your now viewing it in a different timezone etc. Personally, I think timestamp 'storage' and timestamp 'display' need to be treated separately. I also think all relevant information (timezone, offset) need to be stored with the timestamp. I also think the fundamental base timestamp should be stored as UTC, allowing all time calculations to be consistent (free of daylight savings time changes). The user can then manage how the value is displayed by setting timezone and offsets as appropriate (with perhaps the default being the local system settings or whatever offset/tz was stored with the timestamp itself). It is very difficult to predict or understand all the use cases for timestamps. Therefore, any scheme must be extremely flexible. Experience has taught me that one critical component is that at the lowest level, many problems are avoided if the value is in UTC. Problem is, UTC is not terribly human friendly. Luckily, this can largely be automated for many common use cases. Unfortunately, it does also mean that if you are someone who frequently moves between many timezones, your situation will be more complicated. ne of the most frustrating parts of working with timestamps is daylight saving times. This causes complications at so many levels. In particular, I hate the fact change over dates often change and more often than not, those changes are based around politics and at the whim of politicians, which makes programatic handling more complex than it needs to be. -- Tim Cross
