From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric S Fraga Subject: Re: Time-zone in dates Date: Wed, 1 Jul 2015 07:27:32 +0100 Message-ID: <87fv581jfv.fsf@ucl.ac.uk> 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> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:32962) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZABUj-0005U4-Fe for emacs-orgmode@gnu.org; Wed, 01 Jul 2015 02:27:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZABUg-0004to-7m for emacs-orgmode@gnu.org; Wed, 01 Jul 2015 02:27:41 -0400 Received: from mail-am1on0124.outbound.protection.outlook.com ([157.56.112.124]:10272 helo=emea01-am1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZABUf-0004td-Tg for emacs-orgmode@gnu.org; Wed, 01 Jul 2015 02:27:38 -0400 In-Reply-To: <87lhf1i68s.fsf@alphaville.usersys.redhat.com> (Nick Dokos's message of "Tue, 30 Jun 2015 11:08:19 -0400") 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: Nick Dokos Cc: emacs-orgmode@gnu.org On Tuesday, 30 Jun 2015 at 11:08, Nick Dokos wrote: > Eric S Fraga 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. Enough rambling for the morning. Time to get some work done! :) -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1260-gcedef7