[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] Time-zone in dates
From: |
Left Right |
Subject: |
Re: [O] Time-zone in dates |
Date: |
Thu, 2 Jul 2015 01:17:21 +0300 |
My initial case was very similar to the one Michael described in the
telepresence example, except that in my case, I need to assign shifts
to people living in different timezones. I.e. I need to make sure that
a shift assigned to someone in Illinois will end at the same time when
the shift of someone from California begins. One way of doing this is
to set all times in UTC+0, but some of us (especially myself :) live
very close to UTC+0, so I can accidentally confuse my local time with
the universal time. It would be also nicer if shifts were in the local
time of people assigned to them too.
On Wed, Jul 1, 2015 at 6:17 PM, Nick Dokos <address@hidden> wrote:
> Eric S Fraga <address@hidden> writes:
>
>> On Tuesday, 30 Jun 2015 at 11:08, Nick Dokos wrote:
>>> Eric S Fraga <address@hidden> 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
>
>
>
>
>
- Re: [O] Time-zone in dates, Eric S Fraga, 2015/07/01
- Re: [O] Time-zone in dates, Michael Brand, 2015/07/01
- Re: [O] Time-zone in dates, Eric S Fraga, 2015/07/01
- Re: [O] Time-zone in dates, Russell Adams, 2015/07/07
- Re: [O] Time-zone in dates, Don Armstrong, 2015/07/08
- Re: [O] Time-zone in dates, Russell Adams, 2015/07/08
- Re: [O] Time-zone in dates, Eric S Fraga, 2015/07/08
- Re: [O] Time-zone in dates, Titus von der Malsburg, 2015/07/08
Re: [O] Time-zone in dates, Don Armstrong, 2015/07/07
Re: [O] Time-zone in dates, Nick Dokos, 2015/07/01
- Re: [O] Time-zone in dates,
Left Right <=