From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id iGc4HrSqwmNjrAAAbAwnHQ (envelope-from ) for ; Sat, 14 Jan 2023 14:14:28 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id mKThHbSqwmNzYAAAauVa8A (envelope-from ) for ; Sat, 14 Jan 2023 14:14:28 +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 07AFD282F8 for ; Sat, 14 Jan 2023 14:14:28 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pGgMO-0002F8-Ks; Sat, 14 Jan 2023 08:14:12 -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 1pGgMM-0002Es-R9 for emacs-orgmode@gnu.org; Sat, 14 Jan 2023 08:14:10 -0500 Received: from mail-pj1-x102e.google.com ([2607:f8b0:4864:20::102e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pGgMK-0001SH-Jm for emacs-orgmode@gnu.org; Sat, 14 Jan 2023 08:14:10 -0500 Received: by mail-pj1-x102e.google.com with SMTP id b9-20020a17090a7ac900b00226ef160dcaso25223597pjl.2 for ; Sat, 14 Jan 2023 05:14:08 -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=IbVnCFjCTWdh5HYUMtst4UTnpHEk2xa9k6GriLceTbg=; b=mOMLsykv84zB+LOM6GK/t+kQqM7OFUuS8RMJJYLMAEH/7fwHB3P8g4zmB+gOhgdXNy Jhux3Ige90BPbB1TLjScRN47SjyuyaCZ7yyGCSHL0jDFk/62i31saSqMUEVfDHBQnfyh TasE9FQwWIbTmw8bF1qFg6AiQyQSA0C+u9/yNkVflZewKKp185wZJp6w6yPc+B6wrMN6 P1TjScnmV5PhV5p8Sn/nN1CAJFMk1ooohnzITV4x3MxlX+IeYNWTQD4PDjdEyUMEGjqX +amVINE1vcTrWxnx+qJHkRjY/WbixXdKQFxLY0DrHjbXXsNyS3WmO2Lw/HQL5GF8t1oN ZWMg== 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=IbVnCFjCTWdh5HYUMtst4UTnpHEk2xa9k6GriLceTbg=; b=J+tAHNSZld9Yb7wwdYyCmIpQz7HHBm6xV1K1NtLzysorbuKVF8JVr2rFtfFZigORTD UYIHVtbX0+HidXVPotZ0dwDJRjh81F7tR26JZqiy0P3kze93XQ42U7moLpr3pUjtWCnb qIkeNT8Wi+RT07AV9ePPVYy0dQi8jTnZk1EBhxClAa+R869/6SA+JhmKnMhdOhmJa9aW zPi3QyDlRoR19Zs9aQ0FyryrA9KR5dSCmRow0N9tcM6mlHVSD7itmq/xDwgYXZjRtHXq GM+0oj0bW3XsAO89yltk2RaQ0lLrIiYv0Pt1j78Rwl+RWAjvN7vA0XOE4XXm6+GVRWmS BkyA== X-Gm-Message-State: AFqh2kpSg29h9+ciyHkbybcsXz0TOfx0X/jUHWbRCZqoThgmc4kqiNy/ b5bABt1rhu1IU5BKKWpQuwQOwEC5m/w= X-Google-Smtp-Source: AMrXdXviocVx04ubaEgNaHOXfhcu32kXIUO6UpPDKW0VRbWYgo2EX5GCjjui++I0Ub4oDTl4tDFapw== X-Received: by 2002:a17:903:183:b0:194:5e46:67b1 with SMTP id z3-20020a170903018300b001945e4667b1mr14019878plg.21.1673702046733; Sat, 14 Jan 2023 05:14:06 -0800 (PST) Received: from dingbat (220-235-140-148.dyn.iinet.net.au. [220.235.140.148]) by smtp.gmail.com with ESMTPSA id k7-20020a170902760700b00192bf7eaf28sm15829959pll.286.2023.01.14.05.14.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 14 Jan 2023 05:14:06 -0800 (PST) Message-ID: <63c2aa9e.170a0220.3bb49.9ef4@mx.google.com> X-Google-Original-Message-ID: --text follows this line-- References: <86zgamtv6o.fsf@gmail.com> <87tu0t1i0c.fsf@localhost> User-agent: mu4e 1.9.12; emacs 29.0.60 From: Tim Cross To: Ihor Radchenko Cc: Daryl Manning , emacs-orgmode@gnu.org Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda Date: Sun, 15 Jan 2023 00:03:18 +1100 In-reply-to: <87tu0t1i0c.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::102e; envelope-from=theophilusx@gmail.com; helo=mail-pj1-x102e.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=mOMLsykv; 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=1673702068; a=rsa-sha256; cv=none; b=Ga24qqSN/dHjhWBnjPGJHkeFAXeWQKQ4vPpHi0mOiNM63N5UDL1V6yft/VlfUXOB9iUhPG LO0eHgRtJXygjF6mxaR+I8u62eqWi3wm/WqIWl3hvg5yRM5Ra96lmfrj3TBhX0K5wxcyMS NSRzD8VEP1tw8LlE4jbBO7NDMcoE25rm6+qQu/ir1wpzUCrHuH68q5E41qKa2IDnBc54d/ +2B9IFNiY+tuM+0zepQY/Yq486XArNFZ+u6w/D5Sb6/7pk+hoDdtgRkB7nMxvp8NeKm6iI Lez5pMPYgBY+YekyPARWfBHfCvNxM0fpDUVK6Jm/4U8jFkhlXhAihs/rMbQETQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1673702068; 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=IbVnCFjCTWdh5HYUMtst4UTnpHEk2xa9k6GriLceTbg=; b=aePpU088OKX0eDM0OPYt/pYiMDnbNzFKYabsJO0S71lHQMFdPXjx5a3Tmxw9lbJD5yTZGH KrK5k1+5nBrL2pQuzCKQZmU9AkGAhUoo02VGJ0MT6X6aSB96WQWO8iqOnjwgfjxjJJcJUY 0vAC2kyYD2qFFvM1ujrHLawcGEvN4vZ5AmeVQvIWMLEXe2kQETESUYNs3I9zUs4IXQ5c1m xYPVecHRWJYBL5emquE2rrdupd6y+z7GT4HrbbXGxTiHiV3uBYVU1K+leqEe82pHYatGm1 u0V3CpfhkvpHr5KtG3psuRIndU8jtzh0N9jqKaJm3TzITI1kAbXjdEiMilai/w== X-Migadu-Queue-Id: 07AFD282F8 X-Migadu-Scanner: scn0.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=mOMLsykv; 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: -11.06 X-Spam-Score: -11.06 X-TUID: LhaBCxrJ8oy6 Ihor Radchenko writes: > Tim Cross writes: > >> I agree this would be a great feature to add. However, after having >> looked at it in some detail, I realise that not only is it not a trivial >> task, it is actually a very large and complex task and will require >> extensive work which will almost certainly result in breakage with >> regards to backwards compatibility. > > Not really. Our timestamp format, in fact, provides sufficient > flexibility to add extra metadata to timestamps. > > In anticipation to add time zones in future, I have added the following > to the Org timestamp spec (see > https://orgmode.org/worg/org-syntax.html#Timestamps): > > DATE TIME REPEATER-OR-DELAY > > TIME (optional) > An instance of the pattern H:MMREST where H represents a one to two digit number (and can > start with 0), and M represents a single digit. REST can contain anything but \n or > closing bracket. > > Note that REST imply that almost arbitrary suffix can be in TIME without > braking the existing Org timestamp parsing code. > > REST, among other things may be > https://en.wikipedia.org/wiki/ISO_8601#Time_offsets_from_UTC or a valid > value of TZ POSIX variable. Exact details can be discussed. > > Note that TZ should be fully supported by `encode-time' (ZONE): > > (SECOND MINUTE HOUR DAY MONTH YEAR IGNORED DST ZONE) > > We do not need to worry about internal representation and conversions > and simply rely on Emacs. > >> At the risk of over simplifying the matter, I would suggest the big >> challenge here is that there are two somewhat competing (and >> conflicting) use cases. On one hand, you want a high level abstraction >> which makes working with dates and times easy and clear. TO some extent, >> that is what we have now. On the other hand, we need something far more >> complex which is able to handle multiple time zones. This means being >> able to handle both base timezone offsets as well as offset adjustments >> for things like daylight savings time. There is a lot of hidden >> complexity here. You have to handle the fact that daylight saving >> chang-over dates/times are dynamic i.e. not necessarily the same every >> year. This adds the additional complexity of having to somehow track >> historical information regarding such changes, which isn't as readily >> accessible in a consistent manner on all platforms. > > We do not care about the details as long as Emacs can handle this. As > long as the user supplies DST and ZONE somehow, we can rely on Emacs' > support and system TZ implementation. > >> Then there is the other 'messy' stuff. For example, when calculating >> time ranges and number of days, hours/ minutes between two dates you >> need to remember to add/remove the hour if the range crosses over a >> daylight savings period. Similarly you need to ensure you make the >> correct adjustment when changing timezones (consider emacs on a laptop >> for someone who travels a lot between different time zones). Not only do >> you need to take into account the different timezone offset, you also >> need to look at the date and then adjust according to the timezone >> offset for the current timezone at the time of the timestamp rather than >> just considering the current time offset. > > Again, we don't need to worry about this. Once we use `encode-time', > operations on time should just work. This is what we do anyway in most > of Org code. > >> I expect what is needed is an 'internal' UTC based representation which >> is used for all calculations and an 'interface' layer, which converts >> the UTC representation into the local display representation for >> consumption by humans. > > This is what we already to via `encode-time' and `decode-time'. > Check out `org-time-string-to-time'. > >> However, the real challenge here is that this is a very large piece of >> work and it needs someone who is prepared to take it on. I suspect until >> someone who needs to scratch this itch sufficiently comes along, this is >> a feature which will be unlikely to make it to the top of the todo >> list. There are simply far too many existing feature improvements and >> additions people will prefer to work on before taking on this >> one. Things are made more difficult because it isn't the sort of task >> which can be achieved with small increments over time. This is more >> likely to be something which needs to be developed in a feature branch, >> which once it reaches a sufficient level of completeness can be used and >> verified working for a wide variety of environments before then working >> out how to fold it back into the core system and handle whatever change >> management will be necessary. > > Not as much as you describe. Not small work either though. > Most of the machinery is already in place, except some leftover pieces > from early Org days. Hi Ihor, I think you may only be looking at the representation and not considering the actual mechanics which will be required to make this all work. Consider for example an agenda file where the TODO items have been added while I am here in Australia (currently +11:00 w/ DST). Tomorrow I fly to Europe where I will be working for the next 6 weeks. I need all my TODOs with active timestamps to be updated to Berlin's TZ. How does this work? The representation of the timestamps is the easy part. It is the management, display, calculations, etc where the complications arise. From looking at the supported time related functions in Emacs, while most of the key ones do have support for passing in time zone data, there seems little (if any) code to support the lookup and retrieval of time zone data - in particular, ability to lookup time zone data for a specific date, not just a location.