From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Brand Subject: Re: Time-zone in dates Date: Wed, 1 Jul 2015 12:04:03 +0200 Message-ID: References: <87zj3moadx.fsf@gmail.com> <87zj3mv9rb.fsf@ucl.ac.uk> <87ioaav72g.fsf@ucl.ac.uk> <87y4j6tgyn.fsf@nicolasgoaziou.fr> <20150626195749.GG5090@fjo-extia-HPdeb> <87zj3iodr4.fsf@ucl.ac.uk> <87egkugfjw.fsf@pierrot.dokosmarshall.org> <878ub1zlzy.fsf@delle7240.chemeng.ucl.ac.uk> <87lhf1i68s.fsf@alphaville.usersys.redhat.com> <87fv581jfv.fsf@ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:41689) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZAEsA-0001Uw-AH for emacs-orgmode@gnu.org; Wed, 01 Jul 2015 06:04:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZAEs9-0008TV-5k for emacs-orgmode@gnu.org; Wed, 01 Jul 2015 06:04:06 -0400 Received: from mail-vn0-x233.google.com ([2607:f8b0:400c:c0f::233]:43373) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZAEs8-0008Qn-Vo for emacs-orgmode@gnu.org; Wed, 01 Jul 2015 06:04:05 -0400 Received: by vnbf190 with SMTP id f190so5707423vnb.10 for ; Wed, 01 Jul 2015 03:04:03 -0700 (PDT) In-Reply-To: <87fv581jfv.fsf@ucl.ac.uk> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Org Mode Hi all On Wed, Jul 1, 2015 at 8:27 AM, Eric S Fraga 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