Re: Time-zone in dates

[Michael Brand <michael.ch.brand@gmail.com>]

Hi all

On Wed, Jul 1, 2015 at 8:27 AM, Eric S Fraga <e.fraga@ucl.ac.uk> wrote:
> On Tuesday, 30 Jun 2015 at 11:08, Nick Dokos wrote:
>> 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.

As an example for the above I suggest to consider a non-stop flight
with a duration of 1:31:00 from Salt Lake City UT to Phoenix AZ, both
cities in different time zones, here intentionally even the same basic
time zone but one with daylight saving and one without.

> 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.

As an example for the above I suggest to consider noon as an event
bound enough to local time.

Furthermore, e. g. astronomical events can serve as examples not bound
to locality. Or for Eric: A telepresence meeting with the team in
South Australia and the team in UK that is in one single global Org
agenda file shared between the teams.

1) Current Org that supports only local time without time zone

   * Flight from Salt Lake City UT to Phoenix AZ
     <2015-07-01 Wed 10:55>--<2015-07-01 Wed 11:26>
     - *Problem*: Valid only in matching local time zone, here MDT and
       MST.
   * Next noon
     <2015-07-01 Wed 12:00>
   * Next new moon
     <2015-07-16 Thu 03:24>
     - *Problem*: Valid only in matching local time zone, here CEST.

2) When the Org file format would support time zones I would use

   * Flight from Salt Lake City UT to Phoenix AZ
     <2015-07-01 Wed 10:55 MDT>--<2015-07-01 Wed 11:26 MST>
     - *Advantage*: Visibility of the time zones where the event takes
       place.
   * Next noon
     <2015-07-01 Wed 12:00>
   * Next new moon
     <2015-07-16 Thu 01:24 UTC>
     - *Advantage*: Visibility of neutrality regarding time zones.

   All three examples are convertible to all local time zones.

3) When the Org file format would not support different time zones but
   only UTC and Org would support only conversions from and to current
   local time for display and input then it is not visible that
   departure and arrival are in different time zones and in which time
   zones they are

   * Flight from Salt Lake City UT to Phoenix AZ
     <2015-07-01 Wed 16:55 UTC>--<2015-07-01 Wed 18:26 UTC>
   * Next noon
     <2015-07-01 Wed 10:00 UTC>
     - *Problem*: Valid only in matching local time zone, here CEST.
   * Next new moon
     <2015-07-16 Thu 01:24 UTC>

Time zones used in the examples
- MST  :: Mountain Standard Time / Mountain Time (Standard Time), UTC-0700
- MDT  :: Mountain Daylight Time (Daylight Saving Time), UTC-0600
- CEST :: Central European Summer Time (Daylight Saving Time), UTC+0200

Michael