From: Michael Brand <michael.ch.brand@gmail.com>
To: Org Mode <emacs-orgmode@gnu.org>
Subject: Re: Time-zone in dates
Date: Wed, 1 Jul 2015 12:04:03 +0200 [thread overview]
Message-ID: <CALn3zojFcSu-kVW3ZMK4uZrhqerwgK9Bm9=ibCyTBK4Z3p2rDg@mail.gmail.com> (raw)
In-Reply-To: <87fv581jfv.fsf@ucl.ac.uk>
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
next prev parent reply other threads:[~2015-07-01 10:04 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-26 13:40 Time-zone in dates Oleg Sivokon
2015-06-26 14:12 ` Eric S Fraga
2015-06-26 14:33 ` Left Right
2015-06-26 14:38 ` J. David Boyd
2015-06-26 15:10 ` Eric S Fraga
2015-06-26 19:20 ` Nicolas Goaziou
2015-06-26 19:57 ` francois
2015-06-26 21:48 ` Nicolas Goaziou
2015-06-29 13:17 ` Eric S Fraga
2015-06-30 1:17 ` Nick Dokos
2015-06-30 7:36 ` Eric S Fraga
2015-06-30 15:08 ` Nick Dokos
2015-07-01 6:27 ` Eric S Fraga
2015-07-01 10:04 ` Michael Brand [this message]
2015-07-01 11:22 ` Eric S Fraga
2015-07-07 17:27 ` Russell Adams
2015-07-08 15:59 ` Don Armstrong
2015-07-08 16:16 ` Russell Adams
2015-07-08 16:40 ` Eric S Fraga
2015-07-08 17:22 ` Titus von der Malsburg
2015-07-07 17:14 ` Don Armstrong
2015-07-01 15:17 ` Nick Dokos
2015-07-01 22:17 ` Left Right
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALn3zojFcSu-kVW3ZMK4uZrhqerwgK9Bm9=ibCyTBK4Z3p2rDg@mail.gmail.com' \
--to=michael.ch.brand@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).