From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.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 iOH0Hv6HwmPJwAAAbAwnHQ (envelope-from ) for ; Sat, 14 Jan 2023 11:46:22 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id 6AAIHv6HwmP5UQEAG6o9tA (envelope-from ) for ; Sat, 14 Jan 2023 11:46: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 E1E81244B8 for ; Sat, 14 Jan 2023 11:46:21 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pGe2c-0008HE-Mw; Sat, 14 Jan 2023 05:45:38 -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 1pGe2Z-0008Gv-Ve for emacs-orgmode@gnu.org; Sat, 14 Jan 2023 05:45:36 -0500 Received: from mail-pj1-x1036.google.com ([2607:f8b0:4864:20::1036]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pGe2X-0006An-6F for emacs-orgmode@gnu.org; Sat, 14 Jan 2023 05:45:34 -0500 Received: by mail-pj1-x1036.google.com with SMTP id q64so24790528pjq.4 for ; Sat, 14 Jan 2023 02:45:32 -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=taHCUPlIt8o9WWRrhGPFh7o6AyG0cOxd0uKVayinDuY=; b=ndRgtrZwNycgNtQztnZmtRMibx8TdPGXAPDpJav+TjKDgqfKuGqTTrUUGcYm2njBnM FvaCX9WX18QuzX+ETBFk8Vv9C/hMIko1hTeatEcuQpeIG4cDzHk8XmGbnlsdUaxolrhe cK8b0gcwzPPswNH+5qiLP6/8DA5KrSV5FIx/M0GCLj/sSXcwXzjxQZQYHK7zZInBdbiK bideeBak7IhAJjxJf1SJjHr+JJF1DOxSeIIQqcBJisLSRiZfV8S0UmnNC9Tpftu24yAM YTHUM95aU27LBG1m2e99CBmTtXaujLVWFOTWV6l/TEfAKW6qW2FrQIohHUWJA9DImToU 4SRA== 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=taHCUPlIt8o9WWRrhGPFh7o6AyG0cOxd0uKVayinDuY=; b=Qi/Jdjtmn7q/S9QzzuKz2kRuZFqHngXCmKRgXuShu6wPa3Mj3kVSVpsgTQrc8/xwFP IcUUpRN9FzC6wCuuIbTjqEjdBeG1VSppYxdzZxhZEx98RQb68sBAhqM2VnJTJBRrmjww lnfgFWnZcsq8w/mTW4G+UUVo+y0MdWSxhWFvwrEPH9QdsqRMm+LuYF/785WuoMyCxOmk yzZoGPe7IprbKUmNGBoBYIiK9axpvW3/gecmLvTp5kpJK19herRkJdiH/2qHU++YyoAQ ecivmFWZdlN2cdOQJA9m6vZgp6gz5x1TTP4nkSK43Gaoks+Sfh0rdBOQc8FbKlZQvDzy RtcA== X-Gm-Message-State: AFqh2krAyzkSZ/IDzbW6YKjEV2srSlBPRL9XQn7h6sLgdlbuvQQYXaai hZoamLkly5Snd+hJh3t1qQlJ/1jXz80= X-Google-Smtp-Source: AMrXdXuee1teLV8eDCxDbc10A8A/j7YZjRy9cTIqIo15bNQuuXFZ9ykb8Ej+ob5GmuKGIl66aluzmQ== X-Received: by 2002:a05:6a20:f06:b0:b8:4f33:e918 with SMTP id fl6-20020a056a200f0600b000b84f33e918mr197183pzb.46.1673693131425; Sat, 14 Jan 2023 02:45:31 -0800 (PST) Received: from dingbat (220-235-140-148.dyn.iinet.net.au. [220.235.140.148]) by smtp.gmail.com with ESMTPSA id h19-20020aa796d3000000b005825b8e0540sm14989344pfq.204.2023.01.14.02.45.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 14 Jan 2023 02:45:30 -0800 (PST) Message-ID: <63c287ca.a70a0220.4bd14.873b@mx.google.com> X-Google-Original-Message-ID: --text follows this line-- References: User-agent: mu4e 1.9.12; emacs 29.0.60 From: Tim Cross To: Max Nikulin Cc: emacs-orgmode@gnu.org Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda Date: Sat, 14 Jan 2023 20:32:30 +1100 In-reply-to: MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::1036; envelope-from=theophilusx@gmail.com; helo=mail-pj1-x1036.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=ndRgtrZw; 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=1673693182; a=rsa-sha256; cv=none; b=VkuOl3JWOfR9VMYE8eq4Om+8LqkhB/n4y6eCfLpmn7d0tM9/XAjNUyPc3G7dBl7HF8DkUj RUVVhL4DDC2Je+cnmWySpEe8BW3RLz4Nvo7PKPK7sc/QVQlUHRia/LK43UCcET1h/lAz/f IMXrHKqxWwkjsn44joUATTFtQX0uFgqa7q7nE9GEyopz0Ko6EQBAYQ0bqA9l0DB0p0/tFK PLGp6CWn4xnnRVsTddeUuex1IzELoxEsnHxekCE2cdFrFceStfOjXAsE/SbXptI2piHm6y 9n+22p1zsrS4z7GzWKTPRzAgDaieA3FqkCthPZPET3d0KBnKmDCi4sppOmIIXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1673693182; 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=taHCUPlIt8o9WWRrhGPFh7o6AyG0cOxd0uKVayinDuY=; b=sGWeYBprGTVWzmMoLxqCCmz0phw2P8RCGt9mZji44FhySOYGMhwH0GIerXFaCHRlzi+omb bgBq48Z/lc762DbTU8Hj1nIH9IjSv5++M5iW5IBiSQ3cpHsiaWsOFBEZT+Zjq5KBGEGJHu jn2kSwemo9DbZFMV/11Xp3xbd4r19+OFGN4IJ5tAZzsF8PbSZjl4+cKIx18j10fW4CAuKx 9BL0KywOGfl2lZVFTwdxmqmSa7zFGMgXzl//6Wqfxpn6n8JmWkM4RDL1u1wWThx0PuukOz vNaTnowoumJ4Rhfm6qiWyL1j2UV+wbRuRC/2rc7R4Ptq6nhHWhjqxH/hfeYp7A== X-Migadu-Queue-Id: E1E81244B8 X-Migadu-Scanner: scn0.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=ndRgtrZw; 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: -7.76 X-Spam-Score: -7.76 X-TUID: SbocHbR6TbDi Max Nikulin writes: > On 14/01/2023 02:06, Jean Louis wrote: >> This is good for review as related to PostgreSQL database: > > I agree that PostgreSQL is an example of good implementation of time-related calculations. > >> https://wiki.postgresql.org/wiki/Don%27t_Do_This#Don.27t_use_timestamp_.28without_time_zone.29 > > I do not find this section enlightening in the context of this discussion. It is more > related to storage formats of DB than to higher level aspects suitable for applications. > >> It would mean that timestamps become time zone aware. Something like this: >> <2023-01-15 Sun +1> > > Welcome to another set of issues. > > First of all, you have just date without specific time point. It may mean particular > calendar day irrelevant to time zone. ICQ had a bug when they decide to store birth dates > as timestamps. Significant fraction of users received automatic greetings on wrong day, a > kind of off by one error. So dates must stored as dates omitting time and zone. > > Let's assume <2023-01-15 Sun 09:00 +1> > > It may be suitable for timestamps in the past, but future is more tricky. There is no > problem if you are going to watch Lunar eclipse. However if your plan is to attend a local > event there is a chance that you will arrive at wrong time. Sometimes offset of timezones > is changed and it may happen between the moment when you added a scheduled time and the > moment of the event. > > Notice that Org timestamps already associated with a timezone, the one is set in libc > (system timezone, or the one set for particular process). So daylight saving time and > administrative time transitions should be taken into account. So Org timestamps may be > ambiguous (mostly) 1 hour per year around backward time transition, e.g. for timezones > having DST. This case explicitly specifying time offset helps to avoid uncertainty. If org was to add TZ capabilities to timestamps, the underlying format would have to be UTC. My previous post where I suggested there was two 'layers', the underlying storage layer (used for calculations like duration or comparison etc) and a presentation layer (what the human sees, which is often in whatever their local TZ is). While overly simplified, this is basically the approach used by postgres. If org mode was to adopt TZ support for timestamps, I am quite certain that the only sane way to do this will be to store the timestamps as UTC. Anything else will just cause massive complications for anyone who moves between different timezones as well as complicating calculations which cross over DST transition points. I think most people are aware of the challenges of dealing with daylight savings and the fact that the transition date+time into and out of DST can change based on various criteria, including political whims (e.g. Australia eastern DST transition date was changed in 2000 because Sydney hosted the Olympics that year). This means there is also an historical context when calculating and formatting timestamps - it isn't as easy as looking up to see if a location has DST and when the transition date/time is - you have to determine that as of the date of the timestamp. THen we have the further complication of calendar changes and different calendars. For example, many people don't realise that Russia didn't adopt the Gregorian calendar until 1918. For example, the reference to Napoleon earlier is more complicated when considered from a Russian locale. Daryl mentioned elsewhere in this thread that how hard this feature would be depends largely on the available libraries for elisp with respect to working with date/time values. Sadly, the available elisp libraries are inadequate in this area. While many of the functions can be called with an optional argument defining time zone information, there is no library which can retrieve this information in a consistent manner and which supports historical data lookup e.g. what were the DST transition dates for NSW Australia in 1970 (trick questions, NSW didn't adopt DST until 1971). The existing library functions are focused more on simpler time calculations where time zone information is less relevant i.e. running timers, timing command execution, comparing file modification times etc. Sometimes, it is easy to forget that while Elisp is powerful, it isn't really a general purpose programming language like C or Rust or even CL and Scheme. It is primarily a programming language focused on a specific domain, the editor. While it has some great libraries it also has anumber of areas where it lacks the sort of sophistication we have grown to expect with more general purpose languages. A further complication is that accessing date and time related data is very system dependent and there is no high level library which abstracts this so that you can easily get consistent results across all the platforms Emacs runs on. Even the underlying data type can vary greatly (i.e. some platforms use a 64 bit value while others only use a 32 bit one). I therefore suspect that in order to consider adding this feature to org it will first be necessary to add a more sophisticated date+time library to Emacs - probably one which is able to interface more closely with OS APIs - most likely, a C library with an Elisp API which is able to query OS native TZ database information and which implements basic time calculations and conversions between different TZ values. It is likely that such a library already exists and just needs to be added to Emacs. However, in addition to finding an existing library, it would of course also have to be GPLv3 licensed in order to be added to Emacs Another aspect of this feature request which hasn't yet been considered is what to do with respect to exporting data. Will we also need some way to define/set the TZ for exported documents? Are there issues to be considered with respect to code tangling?