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 2Ol1J08I3WOgJwEAbAwnHQ (envelope-from ) for ; Fri, 03 Feb 2023 14:12:47 +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 SO6TJk8I3WNsTwEAG6o9tA (envelope-from ) for ; Fri, 03 Feb 2023 14:12:47 +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 1F77137DD9 for ; Fri, 3 Feb 2023 14:12:47 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pNvrJ-0007aE-5e; Fri, 03 Feb 2023 08:12:05 -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 1pNFOG-00020m-Fp for emacs-orgmode@gnu.org; Wed, 01 Feb 2023 10:51:16 -0500 Received: from [217.170.207.13] (helo=stw1.rcdrun.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pNFOC-0003k4-94 for emacs-orgmode@gnu.org; Wed, 01 Feb 2023 10:51:16 -0500 Received: from localhost ([::ffff:197.239.7.190]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 000000000010394F.0000000063DA88FB.00005141; Wed, 01 Feb 2023 08:44:59 -0700 Date: Wed, 1 Feb 2023 17:38:49 +0300 From: Jean Louis To: Ihor Radchenko Cc: Tim Cross , tomas@tuxteam.de, emacs-orgmode@gnu.org Subject: Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda) Message-ID: Mail-Followup-To: Ihor Radchenko , Tim Cross , tomas@tuxteam.de, emacs-orgmode@gnu.org References: <3035CDD5-41DD-4516-9E4E-9E0DF16BE2E0@gmail.com> <87lelo8c9r.fsf@localhost> <2150768.1675077958@archlinux> <87tu063ox2.fsf@localhost> <87h6w63jgg.fsf@localhost> <86wn51g661.fsf@gmail.com> <87357pn57t.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87357pn57t.fsf@localhost> User-Agent: Mutt/2.2.9+54 (af2080d) (2022-11-21) X-Host-Lookup-Failed: Reverse DNS lookup failed for 217.170.207.13 (deferred) Received-SPF: pass client-ip=217.170.207.13; envelope-from=louis@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -9 X-Spam_score: -1.0 X-Spam_bar: - X-Spam_report: (-1.0 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_SBL=0.141, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Fri, 03 Feb 2023 08:12:02 -0500 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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1675429967; 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; bh=flRI5u6sHCYCF5hcngmU9dzCrSIsG7GcuajqgB8jLcs=; b=VQt6qoVFeP2wq8YfjKLAs+y4Tx5A21LMgAqZkhhmRlw9KD8IATKp7zOOZuL3FxCF6BSWLp E2uImslWuh/HRxvGAfEMlMSPs2kZjQamTEljiPPGAHhS27/r3c5igKeuJZuALjQy4ZoU8D 5kPrZzUp5WUuYEmtRJktDLsfPvFg803VfnFi9wyedOx0olbqm6YgT+HbYE54dQoAxzHwmI NYczGqgKqMFrp4bcSADX2diRBKgyR1JlDudHjInWnqZFwnObXQvJAaewCeq8dfrv9ySMHD 1rWxDO57ggiGSAOl7EmMQ5n0nNUVDy8nt0zj8bKWXzyNsdLbOyDiEYDzVouaqw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; 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-Seal: i=1; s=key1; d=yhetil.org; t=1675429967; a=rsa-sha256; cv=none; b=g6UuV8RuXgUKlycGwh22evwzSaGQBnwDFnqoEMVdK5N5zTLQWHN3v3qikUbLQ4fw1f+mdb 73Y6i6V/CM74VIt89C2lMb2z7q7PIYPbQx/7MiY1+TnBVLe4+GFf7vuJYA77VSOb25oBki D1k5LNqdxNYKy22A1BaUC/98IIrtxQiu0CxAK9m0TXIwSAcnQ5YC/42bS759urV42yCP/Y EFGRiO1Xzb7tQhZDtsq636rX0RPmzY5+yyHfbDdQl8uYhoSvKcKoiY5qPW0RmzAEJzQVcW OTv4V0pXhQ1eT/wFCZfrr4HpbnLuNpQIOlohpQf+8g/3KgMDyOtqnZdvrN2wcA== X-Migadu-Queue-Id: 1F77137DD9 X-Migadu-Scanner: scn0.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=none; 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-Spam-Score: 0.93 X-Spam-Score: 0.93 X-TUID: pK1dKQgiq+lh * Ihor Radchenko [2023-02-01 14:12]: > Let me try to explain better. Just specifying time zone is ambiguous > once per year during daylight transition. For reason to make it unambiguous, people (representatives of countries in international associations) are creating the TZ database, and maintaining it. Specifying time zone is not ambiguous as long as you use the TZ database for specifications! > [2023-03-29 02:30 @Europe/Berlin] is special. I may only guess you wanted to specify the last Sunday in March 2023, where there is UTC offset shift. Your time stamp above is very valid, but you probably wanted to point out to the alleged problem with the daylight savings. The time stamp you maybe wanted to demonstrate would be: 2023-03-26 02:30 @Europe/berlin It is not special case! It is INVALID time stamp. It does not exist in the context of internationally agreed time. In the context of this e-mail, you may write what you want, but you are arguing about something that does not exist. Things that do not exist, do not make you a problem. The only thing that could be ambiguous is the hypothetical, imaginary, lousy software that generates invalid time stamps like that. You are bringing up the problem which in the human agreed reality does not exist. > According to https://www.timeanddate.com/time/zone/germany/berlin, > 2023-03-29 is the time when the clock is shifted one hour back due to > the daylight saving transition. The wall time goes like > > 2023-03-29 02:30 -> ... -> 02:59 -> (CEST -> CET) 02:00 -> ... -> > 2:30 (again!) I got your point, even though you are showing invalid time stamp. And that is not a problem, because TZ database specifies exactly how to calculat time. If you however, use time zones but do not use time zone database, well, that is case of bad program design, and your program, and anything you do in that program will become ambigous as well. > So, [2023-03-29 02:30 @Europe/Berlin] can mean two time points: > before and after the transition. 1. Your timestamp is wrong for demonstration purposes, the time stamp you are displaying is not related to daylight savings shift. 2. The time stamp for demonstration should be: 2023-03-26 02:30 @Europe/berlin 3. The time stamp above, in the number (2) of this list, IS INVALID. 4. Recommendation is to stop using lousy programs generating invalid time stamps. > Specifying explicit offset is thus necessary in this specific > scenario to disambiguate the timestamp: That specification of UTC offset is necessary is out of any doubt. But you have formed your decision in invalid timestamp and lousy programs, thus further conclusions based on such decisions cannot be relevant, and people shall be cautious regarding conclusions that were based on wrong and correct time stamp, where author wanted to point out to daylight savings shift time stamp, whereby such time stamp is invalid and as time representation does not exist. It is because you do not need to worry how time zone is ambigous, because it is not. Please read specification of the time zone definition. It has been defined to solve this type of problems for people. > [2023-03-29 02:30+2 @Europe/Berlin] (before transition) > [2023-03-29 02:30+1 @Europe/Berlin] (after transition) Both of the above time stamps do not exist, both are valid. If you meant daylight savings time stamps, then you maybe wanted to say following: > [2023-03-26 02:30+2 @Europe/Berlin] (before transition) > [2023-03-26 02:30+1 @Europe/Berlin] (after transition) However, above time stamps are INVALID. You deal with non-existent problem. There is nothing to solve there. Practical exercises for people to understand it: ------------------------------------------------ Go in shell: # Following will set your user's time zone to Europe/Berlin, that # indicates that programs shall look for time zone specification, such # as the one in /usr/share/zoneinfo/Europe/Berlin $ export TZ=Europe/Berlin # In the next step, setup the date: $ sudo date -s '20230326 0159' Sun Mar 26 01:59:00 AM CET 2023 # Ask for current time stamp from system $ date 2023-03-26-01:59:22-Sunday # Sorry that I have peculiar system time stamp personally, it is # because I often use it to generate files # Let us see it without my customization $ /usr/bin/date Sun Mar 26 01:59:06 AM CET 2023 # Let us repeat it, while we let time running: $ /usr/bin/date Sun Mar 26 01:59:32 AM CET 2023 # Observe what is happening: $ /usr/bin/date Sun Mar 26 01:59:58 AM CET 2023 ~ $ /usr/bin/date Sun Mar 26 01:59:58 AM CET 2023 ~ $ /usr/bin/date Sun Mar 26 01:59:59 AM CET 2023 ~ $ /usr/bin/date Sun Mar 26 03:00:00 AM CEST 2023 Did we arrive to 02:30? No. Why? How about setting up the date to the imaginary "ambigous" and invalid time stamp: $ sudo date -s '20230326 0200' date: invalid date ‘20230326 0200’ $ sudo date -s '20230326 0230' date: invalid date ‘20230326 0230’ Hmm. Maybe the GNU `date' command simply does it's job well? I wonder why? Maybe it uses time zone specification? And following will work: $ sudo date -s '20230326 0300' Sun Mar 26 03:00:00 AM CEST 2023 The demonstration will tell you that specifying invalid time stamps is what? INVALID. To avoid such time stamps is easy, just stop using crapy programs to generate invalid time stamps. File a bug, complain, but do not use wrong time. Another practical exercises user can do: ---------------------------------------- 1. Go to https://f-droid.org ---------------------------- Try out the free application Etar, and try to enter such invalid time stamp by creating a task with the time of [2023-03-26 02:30 @Europe/Berlin] and user will see that it will not work, the time will be written as 3:30 instead of 2:30 -- application is not lousy, thank you very much, PASS! 2. Do PostgreSQL exercise in shell: ----------------------------------- $ psql psql (14.6) Type "help" for help. [local] maddox@rcdbusiness=# set timezone to 'Europe/Berlin'; SET [local] maddox@rcdbusiness=# select '2023-03-26 02:30'::timestamptz at time zone 'Europe/Berlin'; timezone --------------------- 2023-03-26 03:30:00 (1 row) The exercise will show that when user specify invalid time stamp program recognizes it and assumes that one hour must be added to such invalid timestamp. PASS for PostgreSQL! 3. Google Calendar on Android phone ----------------------------------- I have asked friend to try to setup a task at 02:15 and Europe/Berlin time zone: Attempt to setup tasks worked by itself: https://gnu.support/images/2023/02/2023-02-01/Screenshot_20230201-154514.jpg But as soon as the task was saved, the specified time shifted 1 hour forward: https://gnu.support/images/2023/02/2023-02-01/Screenshot_20230201-154527.jpg Conclusion: ----------- 1. Time stamp like [2023-03-26 02:30 @Europe/Berlin] is invalid. There is no problem at hand unless there is lousy program generating it. 2. People taking care of time should not use lousy programs generating invalid time stamps. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/