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 OAo0B8dbyWOibwEAbAwnHQ (envelope-from ) for ; Thu, 19 Jan 2023 16:03:35 +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 wEBJBsdbyWNXgQEAG6o9tA (envelope-from ) for ; Thu, 19 Jan 2023 16:03:35 +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 9F99A3D08D for ; Thu, 19 Jan 2023 16:03:29 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pIWRL-0007dr-Bu; Thu, 19 Jan 2023 10:02:55 -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 1pIWRI-0007ac-32 for emacs-orgmode@gnu.org; Thu, 19 Jan 2023 10:02:52 -0500 Received: from stw1.rcdrun.com ([217.170.207.13]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pIWRF-0004eA-VX for emacs-orgmode@gnu.org; Thu, 19 Jan 2023 10:02:51 -0500 Received: from localhost ([::ffff:197.239.7.243]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 0000000000103951.0000000063C95B9A.000048D1; Thu, 19 Jan 2023 08:02:49 -0700 Date: Thu, 19 Jan 2023 17:32:35 +0300 From: Jean Louis To: Tim Cross Cc: Ihor Radchenko , Daryl Manning , rjhorn@alum.mit.edu, emacs-orgmode@gnu.org Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda Message-ID: Mail-Followup-To: Tim Cross , Ihor Radchenko , Daryl Manning , rjhorn@alum.mit.edu, emacs-orgmode@gnu.org References: <63c66048.630a0220.427bf.a5f6@mx.google.com> <87r0vtiks0.fsf@localhost> <63c671c0.a70a0220.61aa5.56b8@mx.google.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <63c8f5a6.170a0220.ea8cf.7f96@mx.google.com> User-Agent: Mutt/2.2.9+54 (af2080d) (2022-11-21) Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_SBL=0.141, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 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-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1674140610; 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=+ak8IXWTbfLW1xBFTtPg/NsNxus5zh1N7ezO1fBz3UE=; b=DsUyztJHtpt7C/wg1wevTqfvfHj/7chc2JvCQrWELyOORDSJ/Qh2rQ031ofMGb9hkPqWTg tX4aEsI5d7fqfkA9jquVUkG7bfAMH2ah3MZsTfxfhI9hx6zM8+xDccSVU/YEvNG6NDftVR Vkoe8VEW8Cbw4gE/1asr5yW8N7PDz3xzFYrSnvf1rjWb3unEc/unhO9aoW9gpadSzYirLJ BqHdWtcRd5omBDQVTWbVTN4rQ4HidWW0mjWxhlJi7jxvFRALafjokTgFGF+zhraI8VY8+Y WsuCCsaj/9xQDiNBPYl985b5I7Ztk7RjUQWj0YqgCcwXcdM7l1IpHOsg+kHuNQ== 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=1674140610; a=rsa-sha256; cv=none; b=K6CRdkJnImXJXcqQvRpfuA+u8OccdL2DViFQyqkogV377Nm5FNzW8vNjNUumErESELhVyL qQEAdoFd5djlMBf7eMOMmOaWOCZJg6LfBnrsagtIzjIPNyta06D2meqL/9bJWs9LidZIFH iwAqCRlnkqlz6WXB14mZTnJlZX/x+UWalbomeiikix2qCqeTMuzu+40cvSuHppj22y5c28 QhNZxLcsKRKykzWWmFGvLYSt8MfTYxMayv1gNLrlUTRZljNwNXPyfE0WJXrKgnHcsgclUx 4B94+wihEOA8/w50339vPzxr2RLxoXFPlb609Q0+ZiGKByathjN59Oqbx4MOSw== X-Migadu-Scanner: scn1.migadu.com X-Migadu-Spam-Score: 0.37 X-Spam-Score: 0.37 X-Migadu-Queue-Id: 9F99A3D08D 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-TUID: HMCxBfDyA6mE * Tim Cross [2023-01-19 10:48]: > You completely misunderstood the specific issue being discussed. You > clearly have not been following this specific point being discussed and > your long reply just confuses matters rather than helps. > > This issue is in dealing with the meeting time when the local timezone > changes due to daylight savings time and the fact you have two different > requirements I do not use Org for time stamps. I am using PostgreSQL. My time stamps show correctly (hopefully) as I rely on the design of that software. I may be very wrong. Though as user I want simple thing, to record time, and that time has to be displayed in my time zone, and I want to have functions which will provide for example accounting statement in the time zone of the recipient in Washington, USA. As simple as that. There is no need for Org to deal with daylight savings, as UTC underlying functions are expected to deal with it. Time zone database, C library, I cannot know. But any error there shall go to system maker. Developing such complexity on Org level is not necessary. For Emacs it makes fun to have various calendars, but for international time, that has to be handled by system libraries. > 1. For meeting where all people are in the same timezone, a transition > in/out of daylight savings changes nothing. The meeting time stays the same > > 2. For meetings wiht people from different time zones, when daylight > savings transition occurs, the timestamp needs to be changed. Nothing > needs to happen for the people in other time zones - it isn't their > problem and their meeting time is not affected. Sure, but that is not calculation for higher level like Org, it is for lower level, like system library. Discussion shall be given to developers of GNU C library to solve calculations with daylight savings. If such functions do not exist, then they can be made. > Ihor['s suggested solution was to just use the TZ of the 'meeting', but > that is ambiguous. A meeting doesn't have a time zone and picking just > one of the recipients doens't help as now you just have the issues of > their daylight savings transitions etc. ☺️ A meeting can have time zone. My friend, that is exactly how we do meetings, I have even given examples from my life on meeting scheduling on this mailing list. We say "Greek time 9 o'clock AM" -- and we meet and talk to each other. If there is any daylight saving, so? My computer will think about it. Not me. I have alarm that counts down, I must rely on my devices. See: System time and hardware clock https://www.suse.com/support/kb/doc/?id=000016358 > The Linux kernel maintains a system time. This time is initialized at boot time using the hardware clock(also known as real time clock, RTC, BIOS clock or CMOS clock). As the hardware clock does not provide information as to whether it is kept in UTC or in local time, this needs to be configured explicitly, in YaST -> System -> /etc/sysconfig Editor -> System -> Environment -> Clock -> HWCLOCK. > Linux changing to and from DST > Linux will change to and from DST when the HWCLOCK setting is set to `-u', i.e. when the hardware clock is set to UTC (which is closely related to GMT), regardless of whether Linux was running at the time DST is entered or left. > When the HWCLOCK setting is set to `--localtime', Linux will not > adjust the time, operating under the assumption that your system may > be a dual boot system at that time and that the other OS takes care of > the DST switch. If that was not the case, the DST change needs to be > made manually. As you can see it is up to system libraries and user settings how to provide DST. Org need not touch that, only convert from time zone time to UTC, from UTC to time zone time. > The 'solution' is to record this meeting in UTC tz. However, to make > this 'workable' for most people, the interface for managing timestamps > needs to make this easy. Then again you have to tell that it is "UTC", which means you are already specifying some time zone. You could tell that Org always thinks of UTC, but that again means UTC as mark, must be somewhere placed, all users must know that it is UTC, and again there is need for users to display time in their time zone. What do you achieve by that design? You will get confusion, as you are forcing majority of the world first to understand what is UTC. Computers don't do that, they ask you, where are you? Athens, Greece? Thanks, here is your time. They don't tell you "let us keep meeting time in UTC" confusing users. Follow the decade long trend human usability trend and use time zones. > For example, I would probablyh want an interface where by default, > my timestamps have no TZ data, but if I call the command to add a > timestamp with the universal argument, it will add a default tz and > allow me to easily change it to a different one. Time stamp does not need to have TZ data, and your function desire is just fine and correct. Org file need not have any property of TZ data. What needs property is only when: - Org files is shared or exported so that people in other time zones use that - When single heading as task is shared or some text with embedded time stamps - When user like you change time zone and that change is detected by computer (Org) Which implies that ALL Org exports ever were ambigously created on export! As in HTML export for example: Created: 2023-01-19 Thu 17:31 (without time zone) is very ambigous. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/