Re: Time-zone in dates

[Nick Dokos <ndokos@gmail.com>]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> On Tuesday, 30 Jun 2015 at 11:08, Nick Dokos wrote:
>> Eric S Fraga <e.fraga@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