Eric S Fraga <e.fr...@ucl.ac.uk> writes: > On Friday, 26 Jun 2015 at 21:57, franc...@avalenn.eu wrote: > > [...] > >> It is really simpler programmatically to deal with time offsets >> instead. The downside is that you cannot manage DST and other similar >> peculiarities but the API is much simpler to write. > > Time offsets are not sufficient. My Australia experience involved me > living in South Australia while working with colleagues in the UK. The > time difference throughout the year was one of 8.5 hours, 9.5 hours or > 10.5 hours, depending on the various switches to and from daylight > savings. Very annoying and confusing to manage... > > To be effective and usable, org will need to incorporate time zone > information.
The only reliable way of doing that is to use UTC as the "internal" representation and translate to/from local time on external display/input *only*. In the case of org mode, the "internal" representation is user-visible, so that can cause confusion and some head-scratching. But *any* other method is going to be a nightmare (damhikt). -- Nick
