From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.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 ZROLOUlsxGP2fAEAbAwnHQ (envelope-from ) for ; Sun, 15 Jan 2023 22:12:42 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id gDDWN0lsxGMxBwAAG6o9tA (envelope-from ) for ; Sun, 15 Jan 2023 22:12:41 +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 82C5C32566 for ; Sun, 15 Jan 2023 22:12:41 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pHAIB-0008BL-5M; Sun, 15 Jan 2023 16:11:51 -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 1pHAI9-0008Av-Mo for emacs-orgmode@gnu.org; Sun, 15 Jan 2023 16:11:49 -0500 Received: from mail-pj1-x1034.google.com ([2607:f8b0:4864:20::1034]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pHAI7-0008IO-U5 for emacs-orgmode@gnu.org; Sun, 15 Jan 2023 16:11:49 -0500 Received: by mail-pj1-x1034.google.com with SMTP id dw9so25877624pjb.5 for ; Sun, 15 Jan 2023 13:11:43 -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=wkMyqqmSqrdqh1Znzf3WUVwB9koN4aYiJZ+7qCAYgCc=; b=cvN4SANaH9ZS6QvzhqOUc31m2YhhJT9YYSriNkGT1+ILFb9GIfLpG59D5i+lfbpc4B OV0RbVwr1MMKg3OTujMR9YDbAXB4h2NViDDgyG859McwB6JDl1f2kOVP01NBeRuY9qzO duH3y4MOlADHP5KfpM2PjOkJsWKWd+gcuTzx66lyXzUjxx6zNvhqeayA3p//j5r6eDNI y70N/RzpnCTlkgYP3luL+l0iu6+rVt0+uf5U407dJgfeDWnSShyWEV6pU0ltOA0eyBf5 W0UrNxHi3gUkW3ZmTyricJvU7p6TzQFt8Za94be9NkdjMrEupoUiT8xkWTDsga26JcXG Npuw== 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=wkMyqqmSqrdqh1Znzf3WUVwB9koN4aYiJZ+7qCAYgCc=; b=fcOxtbTsCh52MMwFTFbgWDI1sbJa+3jZCxDwqwmpRauIzjxFsJPWtCac9p0fpLvS9N E480ikc63V8MgZENyhyOCd5GqDoSj8sfhw63OWDs3Miz20Dof/dAG+awKmYzOBKOcWEC j1bRv2alnZ6sIPgzj2KRdpmZQHGamuf59a6e2lFvfpHeteRNTKNXscGy+KvGcVj0FJ2l umc2m3eSaACrYdT7DdmrlJsLga79J2OduDHIyEFFDXt++wLM7vj5MsLWtuXeJ/0bqfsy 1lkyfp/abeZjXOspGyPW2VwLhVeRIy6Btf2avP9tUMfeAI5mZd8ImsyF8/4dmzCuM0II dmrg== X-Gm-Message-State: AFqh2kos9WUtTNHPJ2cggV2t9OEz/xo6G1T44sc2bEfiWjEK0T5LKJZc dtxBHQRVOARFP93FeLK1fn8qQ9CJC0w= X-Google-Smtp-Source: AMrXdXvxMdkdzilroIM8a1a1Fw6C9b94FW+DIbK3RB8FQUrOz6C4eCSuR74R+mY2fs0Iz6FwokS0Ww== X-Received: by 2002:a17:902:9b84:b0:194:9288:dc19 with SMTP id y4-20020a1709029b8400b001949288dc19mr1996884plp.68.1673817102039; Sun, 15 Jan 2023 13:11:42 -0800 (PST) Received: from dingbat (220-235-140-148.dyn.iinet.net.au. [220.235.140.148]) by smtp.gmail.com with ESMTPSA id z12-20020a170903018c00b0019311ec702asm17632987plg.36.2023.01.15.13.11.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Jan 2023 13:11:40 -0800 (PST) Message-ID: <63c46c0c.170a0220.bf97a.b73a@mx.google.com> X-Google-Original-Message-ID: --text follows this line-- References: <63c30f34.650a0220.498b8.4573@mx.google.com> <87ilh7evsn.fsf@localhost> User-agent: mu4e 1.9.14; emacs 29.0.60 From: Tim Cross To: Ihor Radchenko Cc: Max Nikulin , emacs-orgmode@gnu.org Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda Date: Mon, 16 Jan 2023 07:43:19 +1100 In-reply-to: <87ilh7evsn.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::1034; envelope-from=theophilusx@gmail.com; helo=mail-pj1-x1034.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=cvN4SANa; 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=1673817161; a=rsa-sha256; cv=none; b=sXMOntyDbH4rslsl7pb9NCogCEdRR6FTkG8CfEfZmUXnRQGl8Sm1KsMQcoKZNh0G4E6oCD RkfMD+qJD4U6Z5SLU8i1eVE4auN4+iHtpDE3NwJd+Ru9cFhgLOOtwj5omynPH7LOUSre0E uZhxjUVyWxTBKXn4Hl7hu0XJ7JJ4su35OenHZcf20grGpgba5iJgTsBFpdhaDSXUBsUwNA VusijuWfF5Ap3GZc6bRrdxYQsDyrX+QSQ61H9Pyi9a9l0I1hQfJ5J+49GTTEEW50tUfGwS THK/I+2hSL5cgxqr2mJBEic4Pt3KCN/LCLxukouF4YpNo4DZDaWbe6bivirAJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1673817161; 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=wkMyqqmSqrdqh1Znzf3WUVwB9koN4aYiJZ+7qCAYgCc=; b=p0KaoxnW//OSxw5MHZuYGoFitBKQbhW3VT1PYWhTefi8KeRNBndRh358brhERjCEyGEIxF Sj/vDVl4PxxP1z2OuSxHrP3D4rW6b+MSnLgPk4tIuBEN1GfYswig9BuC2JWYril98kK4pm e1dz29K0FTli/CzobSXmPR/5/jgtbnlIuVSh1HM8fv2Vvki2If3Z3Vr4530K7/3LnAsxqe 7Op7dZmrsy6FACfGsskK/dBoA1UkKgxzhOpxNhNpdqhkIxPqRoPw2bHbvKs+Usdl/KCWvA KlA0HTMCFxqoZnv0t8i7Pz4TI1oNp+K4ASw7h6FSVqoluMhn+GXR/PX4b5BDZg== X-Migadu-Queue-Id: 82C5C32566 X-Migadu-Scanner: scn0.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=cvN4SANa; 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: -9.77 X-Spam-Score: -9.77 X-TUID: pSiWYeuNtyHA Ihor Radchenko writes: > Tim Cross writes: > >> Unfortunately, the common abbreviated forms like EST, AEST etc are >> inconsistent here. Some places will have a standard and a daylight >> savings type i.e. AEST and AEDT, while others will have just AEST. TO >> make it worse, two locations with the same time zone offset my use >> different versions i.e. Australia/Melbourn is AEST (+10/+11) and >> Australia/Sydney is AEST (+10) and AEDT (+11) and Australia/Brisbane is >> just AEST (+10). If everywhere which has daylight savings ensured they >> used a different abbreviation for daylight saving and non-daylight >> saving times, life would be easier, but they don't). Then of course >> there are many countries which don't have a symbolic letter abbreviation >> i.e. just have e.g -05 as their abbreviated TZ name. >> >> It is this and other related reasons why just relying on Emacs' internal >> API for times and dates is not sufficient. The abbreviated times have >> ambiguity and the full timezone specification is cumbersome and >> ugly. Even worse is that issue won't be shown up as failures - you will >> just silently get wrong results. > > So, basically we may need a way to (1) identify ambiguous TZ > specifications; (2) signal to user about potential issues. > > Note that these are also optional features we may implement any time > once we have basic timezone support. > > For (2) we may use something similar to `world-clock' - display user > timestamp at point for different time zones. Maybe via eldoc. If the timestamp only contains the abbreviated name e.g. AEST, then there is no automatic way to disambiguate - best we could do is issue a warning. The abbreviated TZ name, unlike the full TZ name, is really just a shorthand for the time offset from UTC at a specific point in time. The full TZ name on the other hand states not only the UTC offset, but also the TZ rules (and with things like the IANA TZ database, the specific TZ rules in place at the point in time that timestamp represents). This is essentially Max's main point - if timestamps for the future have the full TZ name, then we can manage things like changes in TZ database rules which occur after creation of the timestamp or adjusting timestamps (for scheduled tasks) based on changes in location etc). This would not be possible with abbreviated TZ or just UTC offsets. As an example, I'm in Australia/Brisbane TZ and I create a timestamp. If it only has the AEST TZ info, when I travel to Australia/Melbourne org would not be able to identify I'm in a TZ with an offset of +1100 rather than +1000 because both use AEST (for NSW it likely would work as NSW uses AEDT during daylight savings time). However, if the TZ was full name i.e. Australian/Brisbane, then it does know and can adjust because my local TZ has changed to Australia/Melbourne. So I guess the timestamp format and the code which manages them will need the ability to use the full TZ name and not just the abbreviated form (and I guess an option to allow the user to select). In fact, we probably need a way to select between abbreviated/full dynamically as well as you might use the different TZ types as a way to flag which timestamps you want to adjust due to TZ changes (either in TZ db or in user location) and those you don't want changed. I also note a comment from an earlier thread regarding timestamps and historical changes in tz info. I don't think this is an issue. As far as I know, past TZ rules/information rarely, if ever, change. It is only with respect to future dates it is a problem and I doubt there is much that can be done. For example Postgres recognises that a future timestamp may become incorrect due to changes in TZ rules post creation of the timestamp, but they specifically state they don't handle that situation and that their model has an implicit assumption that the TZ rules associated with a TZ don't change. In other words, from their perspectrive, you would have to have a different process which monitors TZ database information and when it changes, examine your db of timestamps for ones which have been affected and adjust accordingly (assuming it matters enough of course). I think org could eventually reach a middle ground - if a future timestamp has the full tz name, then changes can be applied, but if not they cannot and leave it to the user to decide which is used.