From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id CIg9Hgohw2NetgAAbAwnHQ (envelope-from ) for ; Sat, 14 Jan 2023 22:39:22 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id KPlMHgohw2MHZwAAauVa8A (envelope-from ) for ; Sat, 14 Jan 2023 22:39:22 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 1F1893FE4F for ; Sat, 14 Jan 2023 22:39:22 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pGoET-000126-Vn; Sat, 14 Jan 2023 16:38:34 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pGoES-00011Z-6X for emacs-orgmode@gnu.org; Sat, 14 Jan 2023 16:38:32 -0500 Received: from mail-pj1-x102c.google.com ([2607:f8b0:4864:20::102c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pGoEQ-0004gb-EQ for emacs-orgmode@gnu.org; Sat, 14 Jan 2023 16:38:31 -0500 Received: by mail-pj1-x102c.google.com with SMTP id dw9so24279662pjb.5 for ; Sat, 14 Jan 2023 13:38:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:date:subject:cc:to:from:user-agent :references:message-id:from:to:cc:subject:date:message-id:reply-to; bh=k32sby4wR+Q4++HEamRo6hSWzAfVk5pM+s4PB8yRHjU=; b=fKfa05icC3IGcBIBol09NWm0txzERjUDDKp8no4BHOmFAexb6KF+DmE5w5Czy5fzmQ xFrMtqqYFcYY/+vbQkV4aU6pZ4zLG0iLhnO0nE4nMGYx1QoB+cIUt6c9J8WUJhR321Uh V6y/VqAs3zIHwfR/weaAeGAq+tQEgV2P2BuHWtq+UXFhR3zBX7NSeYO9TluO+jC3vxu0 Va+5vTaFBsp3Y2Oq+2Tov6sIUArZxe55dCsAiEOhz8DmnsgWWOOnUVonkDpn5aWNq8h9 BDU7TEbOHYscv4eWbYvVXa3ptvBYKe0kbQniTWxKpsV4xukePiTQ5YPrsTmgz9Br0d11 kNVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:in-reply-to:date:subject:cc:to:from:user-agent :references:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=k32sby4wR+Q4++HEamRo6hSWzAfVk5pM+s4PB8yRHjU=; b=kq2q0DWAlORh+PJdhBAvH4iu97rVJetHEKqO2T3xDlMfPIV9N+V2ogFngSuKxCH+Z9 t3P1Q1F9FqN+DcO8Y2fgxwwhXA6pxzohWB86llXQWcopux71Mtzb8vTgPiZV3qY2In2V NoXnEWzLqEuaKTkjVXITUFkSgH/9wqgnAhgaILjG0DaY5N33M10GtCSjjF9+UP0FX/Om /brypm+sz8nm49L5A6oEMq9VocHKNmmb56iyjNDIvs6HGlfxv3WK3HJAN0teDPiVVfp+ uGQduuXtLBdFLECH6ZNWWwjWeo/j+zK/pBwvl1qxCAoXsODY9stYAVTVoPejaMhRsQ8/ Og/Q== X-Gm-Message-State: AFqh2kqAQW2yhUy0xMLMHkSUKEYcboosHW7u69pB7ineSkyhebmxLbSq Z0NbKFfh4GfpWLpyKJ1vQQ31ZLvHcBY= X-Google-Smtp-Source: AMrXdXu4IrbLrNlYQQC3kleV19IZNtIxHuIIW1gxaj3DIW2CIW3Fq+kQrtUp0XmE0lkfF6SpcrJ3Rw== X-Received: by 2002:a17:90a:468d:b0:229:983:f3f9 with SMTP id z13-20020a17090a468d00b002290983f3f9mr10516046pjf.40.1673732308632; Sat, 14 Jan 2023 13:38:28 -0800 (PST) Received: from dingbat (220-235-140-148.dyn.iinet.net.au. [220.235.140.148]) by smtp.gmail.com with ESMTPSA id mt23-20020a17090b231700b00226f9c7474esm7983134pjb.54.2023.01.14.13.38.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 14 Jan 2023 13:38:28 -0800 (PST) Message-ID: <63c320d4.170a0220.f284d.c997@mx.google.com> X-Google-Original-Message-ID: --text follows this line-- References: <63c287ca.a70a0220.4bd14.873b@mx.google.com> <87pmbh1hgx.fsf@localhost> <63c2b8e4.a70a0220.e3b6d.0051@mx.google.com> <87edrxyyeq.fsf@localhost> <87bkn1yx59.fsf@localhost> User-agent: mu4e 1.9.12; emacs 29.0.60 From: Tim Cross To: tomas@tuxteam.de Cc: Ihor Radchenko , emacs-orgmode@gnu.org Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda Date: Sun, 15 Jan 2023 07:56:37 +1100 In-reply-to: MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::102c; envelope-from=theophilusx@gmail.com; helo=mail-pj1-x102c.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=fKfa05ic; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=key1; d=yhetil.org; t=1673732362; a=rsa-sha256; cv=none; b=CVmHrlCUGHNnr4/1oWnk6+ReNayTIvejxB3dkwb5zUGq1B0vyzaVCqzU7YVsUnKzobPvV0 b2/rmErxTOrCkVb/5M34mPlqqDdzLXSKtBf6YDrTaKx5qSMfdyzu43AFM2sW1zrTE96MfL 1UPKv5fPXLXOSI0e36dB0bHecPb47Nke+datISiQ00uCyKz9ns4T/9Na2bClDzIu7sKlfv MClkLx5tDErraMacWtfQSMdu0c1VNC8+H9MhIdvrY6cjXOGri6e4TcjLddyGa/d8sS6zBS TjBojGMgzMNPT/9Mp2+Xm69Dn8JId3UdJTTFhamIxDq2xkloEPzET6UDAxk2GQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1673732362; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=k32sby4wR+Q4++HEamRo6hSWzAfVk5pM+s4PB8yRHjU=; b=UC/OW5mvAHdh9i41NNPiSlLjjUYqmEc0OP2Nrf6jYS9NU+/EEjD34HkcF98nRDyYjs31iT 8ZoDvX4NdAatnp6NR3SpFQzP4/Cd6043U1kCb4rw5f8JtE8h2cXGTz6XXBcWE/d6VBcuCC WMSBvodKYe78dqrJWtyDn0w/cQEH1QmQQpy1PxuWefySw8sTiytFhfWsaZhYFd8rGnxApa Oz5fu0jbaR1QThELxBYmxRaC3orf7R5ZpsTluPNBxlUHWSziyrTYSqw/1/6Bw/XIug43IM j1WvdqC4ipNw4nQl1aVakWwJidGF8gYEJaqfwoUz7ONFCp9wfLpikVF+PCKVdA== X-Migadu-Queue-Id: 1F1893FE4F X-Migadu-Scanner: scn0.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=fKfa05ic; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gmail.com X-Migadu-Spam-Score: -8.06 X-Spam-Score: -8.06 X-TUID: QZUak92oaxXE tomas@tuxteam.de writes: > [[PGP Signed Part:Undecided]] > On Sat, Jan 14, 2023 at 03:05:22PM +0000, Ihor Radchenko wrote: >> writes: >> >> > Now there's still enough work for the applications to do: presentation, >> > parsing, disambiguation, if necessary asking the user for help. Someone >> > mentioned PostgreSQL -- this is a nice example of what can be done beyond >> > the (comparatively!) boring details of time zone management :-) >> >> Do I understand correctly that PostgreSQL insists on using timestamps >> with time zone info in favour or ordinary timestamps? Exactly to avoid >> issues with the same timestamp pointing to a different real time from >> epoch depending on the current OS time zone setting? > > It doesn't insist: it offers both data types, but the docs are very clear > on what they prefer. > The internal representation of timestamps used by Postgres is ALWAYS UTC, regardless of whether the field was defined as timestamp or timestamp with timezone. The only real difference is that if the field is defined as just timestamp, postgres assumes the data being entered is in local time and will adjust using the local timezone offset. It will ignore any tz information in the input. If the field is defined as timestamp with time zone, it will use the offset defined by the timezone in the input to determine the UTGC value. When displaying a timestamp, postgres always uses the local time zone unless you request a different timezone using the 'at time zone' construct. >> Thinking more about this, I can see how it can be important for >> clocking, and similar auto-recorded information. Users may be surprised >> to record clocking on some task yesterday just to find the clocking data >> in future upon travelling from Singapore to San Fran. >> >> So, when implementing time zones, we may need to take care about adding >> the time zone info when auto-inserting timestamps. >> >> In addition, we may provide some mechanism to set the time zone for: >> 1. Individual files >> 2. For all files, including possible time zone transitions over time. >> >> What I mean by (2) is when the user travels from, say, Australia to USA, >> it could be possible to say: Use Australia/Seattle up to certain time >> and then use USA/Austin. >> >> However, the above considerations are just nice-to-haves and should not >> be a blocker to a more generic time zone support in Org. Having an >> ability to specify time zones manually will already cater needs for a >> number of users. > > Definitely. But the time stamp (with time zone) in itself doesn't > carry enough context to actually decide that. It's even not that > easy to wrap one's head around dates that "travel" (the easiest > example would be perhaps: "9:00 show up at work" -- when DST takes > effect, it's still 9:00 whatever the local time is). When you > have appointments with people in totally diverse time zones, perhaps > dates tend to be more fixed wrt UTC. > One thing to keep in mind is that the abbreviated time zone names are really just abbreviations for time offsets. So AEST is the same as +1000. However, full timezone names represent complete timezone rules i.e. Australia/Sydney is not just an offset value, it can tell us (via the tz database) when daylight savings transitions occur (both for now and in the past). The abbreviated names lack this information and can also be ambiguous because some countries use the same abbreviation for inside and outside daylight savings periods. This means that if we were to store timestamps in org files and use the abbreviated tz name, we cannot handle adjustments due to daylight savings times because we don't actually know the 'real' timezone of the timestamp - we only know the tz offset at the point when the timestamp was created. If we really want a solution which is able to handle mobility and movement between different timezones and adjust for changes in offsets due to daylight savings etc, you need to record the true full timezone name, not the abbreviation.