From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id sFB8N2pLzWMjZAEAbAwnHQ (envelope-from ) for ; Sun, 22 Jan 2023 15:42:50 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id UGZ7N2pLzWPHWgEA9RJhRA (envelope-from ) for ; Sun, 22 Jan 2023 15:42:50 +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 AC5E11121E for ; Sun, 22 Jan 2023 15:42:49 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pJbXn-0006pL-2U; Sun, 22 Jan 2023 09:42:03 -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 1pJbXl-0006pA-E0 for emacs-orgmode@gnu.org; Sun, 22 Jan 2023 09:42:01 -0500 Received: from outbound-ss-820.bluehost.com ([69.89.24.241]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pJbXh-0000Vq-Ji for emacs-orgmode@gnu.org; Sun, 22 Jan 2023 09:42:00 -0500 Received: from cmgw13.mail.unifiedlayer.com (unknown [10.0.90.128]) by progateway2.mail.pro1.eigbox.com (Postfix) with ESMTP id 1382C1004BB95 for ; Sun, 22 Jan 2023 14:41:55 +0000 (UTC) Received: from box2035.bluehost.com ([74.220.219.237]) by cmsmtp with ESMTP id JbXep1YX2NX2aJbXepopVq; Sun, 22 Jan 2023 14:41:55 +0000 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.4 cv=NMAQR22g c=1 sm=1 tr=0 ts=63cd4b33 a=VozZY++RX3oc2UgfNhVfaA==:117 a=VozZY++RX3oc2UgfNhVfaA==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=IkcTkHD0fZMA:10:nop_charset_1 a=MKtGQD3n3ToA:10:nop_fastflux_from_domain_1 a=1oJP67jkp3AA:10:nop_fastflux_mid_domain_1 a=RvmDmJFTN0MA:10:nop_rcvd_month_year a=DPR-AOO6AYYA:10:endurance_base64_authed_username_1 a=A2tt7buDTgEA:10:from_fastflux_domain1 a=pGLkceISAAAA:8 a=o9zw6IYYAAAA:8 a=rBXWRLx_7LtfwpdEYRkA:9 a=QEXdDO2ut3YA:10:nop_charset_2 a=-FEs8UIgK8oA:10:nop_fastflux_domain_1 a=BtxB1_lq3pBo68oZtZ_9:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tsdye.online; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:In-reply-to:Date:Subject:Cc:To:From:References:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=WFjW77PhQwQ+zz20IOw1lT09HNUoG3KPnEf6Gtg594c=; b=C55M2k+1AZSkM9CtIUpGiE/9Dr sO2+NtIFDTRFlEo1Dd3scCbxj19kmqjjM/loXZhqjdjcWvrrLNIeTYJ93HdLnSE9nvZB/snIQykc0 yoFPNRDMb0KU5yQGwKB6qcqrK4qs0ofcWuIvga5jRb69FK7fRCSUb8fW42pzoOTtflaKwGcMZlwci NlpjoWkV4JV2RfYg88yWPmg+IFBJ052Z/l7IpEm2Ksc9XsP2N/s1wmsTHCBoFX89mA8mCtztzjbl7 ddEIgQv9JilNscHHRJTwexoGHmOnuXMI7o7dHbsGVRy4X5GlgZkBsJ3VoiXroZsR1ELnFy9GXvjO4 sXzKI9pA==; Received: from cpe-50-113-33-148.hawaii.res.rr.com ([50.113.33.148]:52852 helo=poto-foou.tsdye.online) by box2035.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1pJbXd-001bOh-Nx; Sun, 22 Jan 2023 07:41:53 -0700 References: <87fsc88aq9.fsf@localhost> <63c7dd3d.170a0220.6b4d6.f84f@mx.google.com> <877cxk6oeu.fsf@localhost> <63c86454.170a0220.80970.652d@mx.google.com> <63c8f5a6.170a0220.ea8cf.7f96@mx.google.com> <63c9b654.170a0220.d82d2.4254@mx.google.com> <87lelxk87a.fsf@tsdye.online> <63ca5101.630a0220.b2298.3363@mx.google.com> <87h6wljhce.fsf@tsdye.online> <87cz79j5gu.fsf@tsdye.online> <63cb3036.170a0220.3ea60.3a93@mx.google.com> <878rhwk8jk.fsf@tsdye.online> <874jsjkgpf.fsf@tsdye.online> User-agent: mu4e 1.6.10; emacs 27.1 From: "Thomas S. Dye" To: Max Nikulin Cc: emacs-orgmode@gnu.org Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda Date: Sun, 22 Jan 2023 03:35:40 -1000 In-reply-to: Message-ID: <87mt6aiqbz.fsf@tsdye.online> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box2035.bluehost.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tsdye.online X-BWhitelist: no X-Source-IP: 50.113.33.148 X-Source-L: No X-Exim-ID: 1pJbXd-001bOh-Nx X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: cpe-50-113-33-148.hawaii.res.rr.com (poto-foou.tsdye.online) [50.113.33.148]:52852 X-Source-Auth: tsd@tsdye.online X-Email-Count: 2 X-Source-Cap: dHNkeWVvbmw7dHNkeWVvbmw7Ym94MjAzNS5ibHVlaG9zdC5jb20= X-Local-Domain: yes Received-SPF: pass client-ip=69.89.24.241; envelope-from=tsd@tsdye.online; helo=outbound-ss-820.bluehost.com X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 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, FROM_SUSPICIOUS_NTLD=0.499, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_PDS_OTHER_BAD_TLD=0.01 autolearn=no 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=1674398570; a=rsa-sha256; cv=none; b=roA/aOLHx2S07FGUD11mfc3KVil9C7+5HTr/MJ0qGhAeDFUH/TQ+x0StucPA6qhUy+XbQY 4w/Bw9PgkqJgok/yc19y3JmIyK/8nRbQZjAGOWfdxv/fuW1238/4PTaVq7GwQuVZusFIJQ T6SiLhL7+WHmCROtctpPGxTQfju9WPZ61DwjdUGdn2TRJ6bj+0K9wKyY6z3PDsb5AiWOWB rpaDu+cyCuqyM3Bo5m3l9ElgkxQkGBNjacHIgCIwJP1W/6M429+be529SBIfwPGhgzB3UN hhwcDSOs6rpBCZu6wNnKxx3RVQseQgxhaiEfCyO5CWDbpM0rh0GJoThWvxk5+Q== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tsdye.online header.s=default header.b=C55M2k+1; dmarc=none; 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" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1674398570; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=WFjW77PhQwQ+zz20IOw1lT09HNUoG3KPnEf6Gtg594c=; b=q93gyXrBAIJXX3oN3Iz8AgMrdpjmUljivhF+u4v/m1q9E91zVLesLKMJ5S/T1flKCzVHiT 5tudQHia75Q5R9sQjJxsCOhGh75Ea/MzMmYACm2xPWvJMP64dgmPPwWYcC2OEI8uabCkKL +XZt+A9Cqj2GL2bK5Ak8+b4HFeN7f6FXcT78uwujcB+DdjrwExhfoiBFOh+EcToP25RTzY qXQ/MaoI6tUHHoj7DBE+JkZJCOrALN2Jhlizveuudwj7o+55rY788TU1hT+cV4qXBF8xlx 19Vx6Ej2ZUPIARgoFsD7XL5tqowZksmZz/KGZG5++QJ9hFE4dbPeLh/Add/xQA== X-Spam-Score: 0.81 X-Migadu-Queue-Id: AC5E11121E Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tsdye.online header.s=default header.b=C55M2k+1; dmarc=none; 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" X-Migadu-Scanner: scn0.migadu.com X-Migadu-Spam-Score: 0.81 X-TUID: Bj+LDcmVmfOL Aloha Max, Max Nikulin writes: > On 21/01/2023 22:55, Thomas S. Dye wrote: >> Aloha Max, >> >> Max Nikulin writes: >> >>> On 21/01/2023 07:37, Thomas S. Dye wrote: >>>>>> 1) Occurrence, where the timestamp includes UTC; >>>>>> 2) Event relative to user, where the timestamp does not=20 >>>>>> include UTC >>>>>> or a >>>>>> time zone; and 3) >>>>>> Event not relative to user, where the timestamp includes=20 >>>>>> the >>>>>> relevant time >>>>>> zone. >> >> I'm curious to find out how the distinction between past and=20 >> future >> makes a difference. > > For timestamps in the past "absolute" time is almost always=20 > known, so > beside timezone identifiers like Australia/Sydney it is possible=20 > to use > UTC or fixed offset 2023-01-21 Sat 05:55:54 -1000. If a=20 > timestamp in > future is bound to specific timezone then its identifier must be=20 > used > since the government may change time offset. Of course there are=20 > cases > when UTC or timestamps with fixed offsets are used as well: e.g.=20 > Lunar > eclipse or participants with multiple locations are expected. Yes, of course! FYI, lunar eclipse was Ramsey's example of an occurrence, which=20 has to do with changes in the relations of things at a time. > > So it is "feature" of some timestamps in future that attempt to=20 > store > them in UTC may lead to their invalidation later. Yes, these are events, which are relative to a timezone, either=20 implicit or explicit. > >>> As to format for storage timestamps in Org files, particular >>> timestamps may have >>> or not explicitly specified timezones, but it is unrelated to=20 >>> these 3 >>> cases. >> >> I'm curious to learn the classification unrelated to these=20 >> three cases >> used to determine when to store UTC and timezone. > ... >>> From my point of view these, 3 cases might be relevant to=20 >>> date-time >>> picker UI, >>> but not for storage format. While parsing, interpretation of=20 >>> each >>> timestamp >>> without explicit timezone depends on preferences chosen at=20 >>> higher scope. >> >> I'm curious what these preferences are, or might be. > > Is the following timestamp is in user local timezone or in UTC? > > <2023-02-01 Wed 15:00> > > If features like the following is implemented then it will not=20 > be in > local time zone: > - file-local > > #+TIMEZONE: UTC > or > > #+TIMEZONE: Australia/Sydney > - subtree-local > > * H1 > :PROPERTIES: > :TIMEZONE: Australia/Sydney > :END: > > So looking at such timestamp it would be hard to choose=20 > particular case > from the set you proposed. > This might be a feature, not a bug. A timestamp that does not=20 indicate absolute time (UTC or fixed offset) and does not include=20 a timezone relies on the timezone set by user. So user changes=20 timezone preference during trips and these timestamps become=20 relative to user's local time. A timestamp with absolute time or with a timezone would ignore=20 user's timezone preference. > Of course it leads to tricky cases when some timestamp is copied=20 > to a > scope with another time zone. It requires some yank handler and=20 > text > properties. When timezone is added to a subtree, perhaps, all=20 > timestamps > inside may need to be changed from implicit timezone. > Perhaps the solution here is to consider this a feature, not a=20 bug. When displaying an event timestamp, the timezone should=20 always be indicated. For an event relative to user, this would be=20 the preference currently in scope. For an event not relative to=20 user, the timezone will be part of the timestamp. > For storage format I would use another types > - explicit/implicit time zone Yes, explicit for events not relative to user, implicit for events=20 relative to user. > - Specific timezone/fixed offset. UTC and Etc/GMT-11 zones are=20 > identical > to +0000 and +1100 offsets accordingly. Here, absolute time is best, either UTC or fixed offset from UTC=20 (don't underestimate legislators' folly changing timezones). > > For UI it is better to choose some terms to make the manual and=20 > UI > dialogues more clear. Agreed, though I don't have suggestions atm. > I am not a native English speaker and terms "event",=20 > "occurrence" sounds > confusing for me. E.g. a conference is an event. A regular=20 > meeting (even > when scheduled in another time zone) or "brush teeth" are more=20 > close to > occurrence. As soon as you have to split "event" category into 2=20 > parts > perhaps it is better to pick 3 different names. I may ask for=20 > fourth > that is absolute, but not UTC, but I would prefer to not insist=20 > on > namely UTC and use fixed offset instead. > Yes, UTC and fixed offset (from UTC) are two ways of specifying=20 absolute time. Neither one refers to a timezone. > For UI it is meaningful to name > - default time zone for this scope (with a hint if it is=20 > currently > system-wide, file-local, or specific to subtree), so no explicit > timezone will be set. > - absolute (UTC or fixed offset) preferred for global event > - bound to location (e.g. Australia/Sydney) > - ad-hoc timezone that follows user in their trips (close to=20 > Ramsey's > "occurrence"). I think the first and last can be considered identical (see=20 above). Also note that ad-hoc timezone is an event because it specifies a=20 timezone, which is a space/time unit. > The problem is to push users to timezone identifiers for future > timestamps associated with some location. Offsets must be=20 > discouraged > this case, but encouraged for on-line meetings. For past=20 > timestamps > particular choice is less important. That is why I separated=20 > future/past > timestamps. > Yes, good point. >> Agreed.=C2=A0 The boss needs to inform you what her local time will=20 >> be for >> the meeting by sending you a timestamp with a time zone.=20 >> Ideally, Org >> would know how to associate the timestamp with a recurring item=20 >> stored >> locally. > > Unsure it it may be implemented reliably. Then Org user must understand that repeating timestamp for an=20 event not relative to user is fixed to one timezone and is not=20 appropriate for an event that might change timezones, as when the=20 boss travels but insists on fixing staff meeting to her local=20 time. > >> Nowadays, I am frequently asked by applications to give=20 >> permission for >> using my location.=C2=A0 When I give it, the application reports=20 >> back with my >> local postal code, etc.=C2=A0 I'm assuming Org can use location to=20 >> determine >> my current timezone. > > libc has a concept of timezone. I think, it should be the=20 > primary > source. It is initialized on application startup (roughly) from > system-wide settings, may be overridden by TZ environment and=20 > changed > later by setting another value of TZ. The problem is that=20 > identifier > like "Australia/Sydney" is considered implementation specific=20 > and is not > directly accessible from the code, it is sealed inside the=20 > library. > Another issue is that I do not know if Emacs is able to receive > notifications on change of system-wide timezone. > > Web-application may request time zone settings from the browser: > new Intl.DateTimeFormat().resolvedOptions().timeZone > > Android devices may have outdated and incomplete zoneinfo=20 > database. This > case either computations should be performed on the server or=20 > tzdata > copy should be bundled into the app. > > Client-server application may use resources maintained on=20 > servers, emacs > must be able to run off-line and enough user will be unhappy=20 > noticed > some outgoing queries. > > Ubuntu installer or e.g. Google relies on GeoIP databases. > > Geodata for timezones is available, but laptops or desktops=20 > mostly do > not have GPS receivers. IP behind NAT is not useful to determine=20 > location. > > It is possible to make GeoIP database (quality of ones available=20 > for > free are not high) and map of timezones, but I do not think it=20 > is > reasonable. > > I suppose, system timezone would be enough for Org. Third party=20 > packages > might implement another way. Thanks. Much appreciated. So, Org user will need to understand=20 that timezone calculations will only be as current as libc and=20 that user is responsible for setting local timezone. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye