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 0IHdOZ6PwmN1ZAAAbAwnHQ (envelope-from ) for ; Sat, 14 Jan 2023 12:18:55 +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 WEWXOZ6PwmPN/gAAauVa8A (envelope-from ) for ; Sat, 14 Jan 2023 12:18:54 +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 96EF7251F0 for ; Sat, 14 Jan 2023 12:18:54 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pGeYI-0005gJ-4G; Sat, 14 Jan 2023 06:18:22 -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 1pGeYF-0005fg-VQ for emacs-orgmode@gnu.org; Sat, 14 Jan 2023 06:18:20 -0500 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pGeYD-0003Dj-97 for emacs-orgmode@gnu.org; Sat, 14 Jan 2023 06:18:19 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 206252401A5 for ; Sat, 14 Jan 2023 12:18:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1673695094; bh=VGENzMy0/U15yYe+QYsTXLpr0R57KTo8OVmBOMqmTDY=; h=From:To:Cc:Subject:Date:From; b=Qsb79wBVeHFRpEEjjQOFv9NsCN5RwydUN/7P24vh8GmroC9AOI/cdKysgSHJVzpF2 SQEhOOCHncPurE/8Ds1On1WXx+Uc4uVzNEEivyzViECmMn4Xm4nXn1QeMZKeGXb4TZ pFyTUxrxf7BxqP/LwF1Y5vuqbfClwjju+OmNmXE6GyLEW53Ju6KTC9DySrnyE5rif2 Ad7bIToqnYn7nfmQwJlcTfA4RvlHBbqFfUNyntqdv5RGbLAj9VrAw99t6Z1v94otZf sBftcReNALpeT4zo5MDx7hp0ozW0HsPEkQPLqmwfIA/l5JrSTBieJSVpWL+98tDUGJ J9GRvVZfDrH6w== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4NvG446Vlvz6tm9; Sat, 14 Jan 2023 12:18:12 +0100 (CET) From: Ihor Radchenko To: Tim Cross Cc: Daryl Manning , emacs-orgmode@gnu.org Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda In-Reply-To: <86zgamtv6o.fsf@gmail.com> References: <86zgamtv6o.fsf@gmail.com> Date: Sat, 14 Jan 2023 11:18:43 +0000 Message-ID: <87tu0t1i0c.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, 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-Seal: i=1; s=key1; d=yhetil.org; t=1673695134; a=rsa-sha256; cv=none; b=DrjdptwrQ1gl3tz/H0VjcqKJbA/WJNApxaWLr4FApjYwc3TbDoWdb0eoYt9K9ao2MfJEej 8z+tPQErJkll9mfR73oagSf3qMWd4dqteyt2TJt7NnDC8jp0POdqXbfGm2R1zY4FStV47A 5LBHuAzMsoKkAq5qG/wSZnLibLlqyAS3XDHUAvNb9OiXIPhyXYpPS6d6lc05kWN9wBNr9H +KXHEnuNKmezwQoMfWa0Pt8zf2m1YzjpcM2dOE+s8+NeehNGRRba8RxI9HjhrGeXZttafE KTD2NJRK3b2+86/FHfMBt/VDhVjSp2WfJHugXWLumrFbkw3WY3b7qpgUITbIVA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=Qsb79wBV; 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=posteo.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1673695134; 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=Rvt3Lk33pjW27WL3FenLS0aKzlSgPGXFR7C1AhupyFA=; b=t0zNg6YWa+XKAs0HIy9ZU8r0jj8tgUNgT/41rGPXqTmhteXQz5kuZ5rorXar3LPV/M8IDB MbOVO4vbUF2YwHTpKVuiZMguD2jW6t3vaTttjGPVgj+fs7lxG4TYp8+MJlnALSe2fHfzkZ B5Q4ehapXyK7ypqNWZaHUZyArtzuJfPHzaCZ1XWifqQc2LYKeFpasn8Gz4r4L2x8xCVcQc IpnPnOCogApuoSkUMar+DUuOz8234b3KDvSGwMBWLs9EZP3EhBKHbYzW2vzYfRABmj2F4W 808yAeoy0Eq/YNSKK95pCK4D4Z77j9tdkpNxv865Mfy/Wh2iTlBTpOuecG6jmA== X-Migadu-Spam-Score: -6.05 X-Spam-Score: -6.05 X-Migadu-Queue-Id: 96EF7251F0 X-Migadu-Scanner: scn1.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=Qsb79wBV; 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=posteo.net X-TUID: 5Y26GWswya8a 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. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at