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 IEIAKsDx1WMsdAAAbAwnHQ (envelope-from ) for ; Sun, 29 Jan 2023 05:10:40 +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 yI3aKcDx1WP9tgAAauVa8A (envelope-from ) for ; Sun, 29 Jan 2023 05:10:40 +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 1D0B3294E8 for ; Sun, 29 Jan 2023 05:10:40 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pLz0i-0004oE-DY; Sat, 28 Jan 2023 23:09:44 -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 1pLz0g-0004ny-Ib for emacs-orgmode@gnu.org; Sat, 28 Jan 2023 23:09:42 -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 1pLz0d-0002oZ-Pt for emacs-orgmode@gnu.org; Sat, 28 Jan 2023 23:09:41 -0500 Received: from localhost ([::ffff:102.85.217.47]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 000000000010B84A.0000000063D5F183.00006CDB; Sat, 28 Jan 2023 21:09:38 -0700 Date: Sun, 29 Jan 2023 07:09:11 +0300 From: Jean Louis To: Tim Cross Cc: Sterling Hooten , "Thomas S. Dye" , 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 , Sterling Hooten , "Thomas S. Dye" , Ihor Radchenko , Daryl Manning , rjhorn@alum.mit.edu, emacs-orgmode@gnu.org References: <63c9b654.170a0220.d82d2.4254@mx.google.com> <87mt6e86sr.fsf@tsdye.online> <63c9d976.620a0220.a7d40.113b@mx.google.com> <87tu0mjb24.fsf@tsdye.online> <63ca1283.170a0220.5bc81.0fdd@mx.google.com> <87pmb9k8oi.fsf@tsdye.online> <3035CDD5-41DD-4516-9E4E-9E0DF16BE2E0@gmail.com> <63d43ec5.630a0220.87fac.44e2@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <63d43ec5.630a0220.87fac.44e2@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: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1674965440; 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=4SjTwVZti/mOSDOjaG296v7fsg9z8nwku6b6XZtilxI=; b=XPts8+lGszGT5fnC6Z3XQI1X2sfvtEpTWLE99do76BEXFrF5LRnYOQtOA5Vs+5r06qgFqA Rl2uGpyhoMEhjPyESnxfYpwoCHrlPYp0vqT484YpMKxN4ldrXDH1f7HyyxxNez+oiw5wkz Q2EPGd4alv9Y5t05QXpHi8fwlWFvof3RO4IV3md5JE9lWnmKpcebUe6aPKlepbvJfyD0NR KT7noW775b2GxVpJr5wjLZT/8H7T/RaiVy++JPBBb/N3GxUMU+j+p/f9EnOjwjiyR0hvtc tY60eT+kRcXCiLP2FYyzmgmQuksPLNpuBSHTpKxEux+jGhC2WnY0cA3Bk5pZ1A== 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=1674965440; a=rsa-sha256; cv=none; b=fCgUj7VHT5QCOwjXBQnfnzfOsbCZ/zmtxaobFEsZh21J08m8P0Izb0YTfx/hqXkNpOHbAB S9Qei0wbFsr7s24elD3pgfbtpR1a6AD5tbMladbO/CW+VFGFrSbVo/0R4RmCZGEUnvdbPW AldBtI0oq2nYBPMUWOUeC89YuV1LZm3RSQe21WU6O7sl9M7deeLQpHNPFeUzIYhOEllnVN DuZ3SyKYxi6hMQ64dl+XxZznNrOLjpkhaJLV5TfWc7KFebtHvNKkRm/A7IBsuXCV0apTfP rMB0RspGqJg4+d60gFpHxMc5OQ91SV3uSdfSxooVFmvZ2GJwI2gS++Rv9hmurg== X-Spam-Score: -2.87 X-Migadu-Spam-Score: -2.87 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-Queue-Id: 1D0B3294E8 X-Migadu-Scanner: scn1.migadu.com X-TUID: fJP5+hBegNBl * Tim Cross [2023-01-28 00:15]: > > > >> What kinds of representations would a calendar system capable of > >> handling timezones require? > >> > >> • Instant (fixed) > >> • This is referring to an unambiguous moment in time > >> • e.g., 2007-02-03T05:00:00.000Z > >> • Offset (fixed) > >> • This captures the idea of "when did it happen for the person who > >> made the observation" > >> • e.g., 2007-02-03T04:00:00.000+01:00 > > > > Offset is not that fixed, maybe from viewpoint of storage as maybe it > > is considered fixed in it's representation, but you have to keep in > > mind that time offset by it's definition is changing itself, suddenly, > > depending of daylight saving and time zone. > > > > I think your misinterpreting the intent here. If you specify a timestamp > with offset, it is fixed. That is what you say. And I am pointing out to international standard references. If you use offset as "fixed" it means such use would not be by standard, and you would confusing users and programmers who are using standard for calculations in programs. > It does not change with daylight savings or any other change in > rules for a time zone. It does not even specify a time zone. And while and before making that decision, did you review the standard that time zone offset is influenced and changed by daylight savings? It does not specify time zone. But it is derived from time zone, and is not same from time zone. Are you aware that time zone offset could have "skipped time" or "added time" due to daylight savings? That implies that by using time offset, you would forget daylight savings which are international standard, and make calculations wrong, because you started applying own standard in Org. Time offset does not independently exists without time zone. While you represent it without time zone, you have to observe time zone first, before deriving time offset from it. Read from: https://en.wikipedia.org/wiki/UTC_offset ,---- | Daylight saving time | | Several regions of the world use daylight saving time (DST) and the | UTC offset during this season is typically obtained by adding one hour | to local standard time. Central European Time UTC+01:00 is replaced by | Central European Summer Time UTC+02:00, and Pacific Standard Time | UTC−08:00 is replaced by Pacific Daylight Time UTC−07:00. `---- Maybe you wish to include a new type of time representation, something like "Org time offset", in that case you are involving Org developers into even deeper problems, as then with the new type, you are left all alone to make that thing work. That new type of "fixed" time offset, would not be standard, and would confuse careful users and programmers. Example: - time offset would be PST UTC-08:00, for example 12:00 o'clock - with daylight saving time event (the time when people switch clocks), the offset of PST UTC-08:00, would suddenly become UTC-07:00, and the time offset would suddenly become 11:00 o'clock in that moment - now is your decision if you will keep counting 12 o'clock in Org, thus creating new type of time specific to Org or 11 o'clock as that is the international standard. Time offset will change with daylight savings, and must be thus derived from time zone. > While it is true that a specific location may have time zone changes > or that the offset from UTC might change as a result of daylight > savings, an offset specified in a times stamp does not change and is > fixed. This is one of the limitaiton with using offset. It is fixed only if you think is fixed when it is written once, and then you think it is fixed. In the sense of calculation of time, it is not fixed and for any calculation of time offset you need to observe in which time zone is that time offset, and if you do not know time zone you can't calculate it correctly. Please read Wikipedia article explaining it clearly. Please read how in China time offset is not every 15 degrees, and how there is wording "Although nominally" and "every 15 degrees". Time offset is thus calculated based on time zone and other factors. It is derived. It is not basic time type to be used for other calculations! It is a difference of time that is mostly in this way, but shaped by politics in other way. Time zone is time added or deducted from UTC. But not just added in mathematical sense, it is added by considering daylight savings, and time zones and politics. > I also think it is a mistake (which I've seen others suggest in this > thread) to equate an offset as being an abbreviation for a time > zone. That is very right. Time offset may be derived from time zone by using tz database, but it cannot just be automatically derived. Time offset is not derived from UTC, it is however, derived from tz database, observing time zones, politics. > For example, some have suggested things like +10000 being the same > as AEST and both being abbreviations for Australia/Sydney outside of > daylight savings periods. I think that is incorrect. Using time offset for calculations is useless as it lacks the time zone, and is only one way of representation for those people who do not understand time zone. However, time offset is NOT fixed, it is representation based on time zone, politics, tz database. Please read carefully here: https://en.wikipedia.org/wiki/Daylight_saving_time and search for time offset to find references. > +1000 is a fixed offset from UTC To say that it is fixed you will confuse people here. When you say "fixed" you must say in which context it has been fixed. I have given you enough examples in this e-mail to understand that time offset in the context of programming is not fixed, as programmer would need to know the time zone, and time offset may be in different time zones same! Thus deriving time zone unambiguously from time offset is not possible. You could derive some time zones, but not all. In this context is not fixed. Deriving UTC time from time offset by using time offset time stamp IS possible. In that context it is "fixed". Deriving positive or negative time difference from time offset is not unambiguously workable! (Unless you make Org new type of time) This is not workable because time offset does change with daylight saving time and also by politics. And to know how it change, again you will need time zone. In this context it is NOT fixed. Another good reference: https://dba.stackexchange.com/questions/94841/how-to-check-the-timezone-for-a-given-datetime Where the main Answer says: ,---- | a DATETIME value and a Timezone (name) then you can determine the | Offset by looking up what the Offset was at that point in time (see | below for sources of such data) `---- ,---- | The "offset" is a property of the timezone, but it does not, and | cannot, determine the timezone since: | | - several timezones can share the same offset | - timezones can come and go and can even shift their offset | - different regions can change their timezones `---- And then this following, well expressed answer: ,---- | With only the Offset, the DATETIME value can be converted to UTC, but | not to another Offset without first having a Timezone database and | knowing which specific Timezone you are converting it to, which will | indicate the Offset for that particular point in time `---- Another problem is that several online explanations on Stack-what are not giving proper explanation. Please be careful when you go searching various programmers statements on Stack-what websites, as programmer may make wrong functions in this or that programming language, thinking: "Oh, that ain't workin', that's the way you do it" Conclusion: ----------- Time offset is offset to/from UTC time, derived from time zone, and is only fixed for that specific time point. It cannot be used to derive other offset, or for programming calculations without using time zone. Time offset is only a different representation of time. If it is valid representation depends who and how calculated it. But let us assume good program did so. When it is properly represented, it cannot be used as "fixed" time to calculate differences in time as it lacks time zone information, and because time offset is changing due to daylight savings and political decisions. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/