Eric S Fraga <e.fr...@ucl.ac.uk> writes: > On Tuesday, 30 Jun 2015 at 11:08, Nick Dokos wrote: >> Eric S Fraga <e.fr...@ucl.ac.uk> writes: >> >>> On Monday, 29 Jun 2015 at 21:17, Nick Dokos wrote: >>>> 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). >>> >>> This may be the correct approach although I worry about losing >>> information by only storing UTC. Whether this information loss is >>> important or not is difficult to predict. It may be of ephemeral >>> importance only. >> >> In what way are you losing information? > > Sorry, should have been clear: the time zone information itself. By > reducing to UTC, you lose one bit of information. Whether that matters > or not in practice is not clear but I'm always uncomfortable when > considering data representations that lead to information loss. > > I've been trying to come up with an example that would illustrate the > problem but I've failed so far. > > Funnily enough, the one example I can think of that would be difficult > to manage with UTC is the case of not wanting to specify a time > zone. Somewhat contrived but, for instance, wanting to do something > every morning such as brushing my teeth. This would be, say, at 7am > regardless of which time zone I'm in. If this were stored in UTC, it > would be at a different time depending on where I was at the time. >
This is actually a pretty good example. This and Michael Brand's examples make it clear that storing (just) UTC in the file is untenable. Nick
