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 qFR1GrXB6GPoLAEAbAwnHQ (envelope-from ) for ; Sun, 12 Feb 2023 11:38:45 +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 kBuaGbXB6GMahQEAG6o9tA (envelope-from ) for ; Sun, 12 Feb 2023 11:38:45 +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 C8FC81AD1E for ; Sun, 12 Feb 2023 11:38:44 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pR9kF-0001QJ-F1; Sun, 12 Feb 2023 05:38:07 -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 1pR9kE-0001QB-73 for emacs-orgmode@gnu.org; Sun, 12 Feb 2023 05:38:06 -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 1pR9kA-0000gb-8W for emacs-orgmode@gnu.org; Sun, 12 Feb 2023 05:38:05 -0500 Received: from localhost ([::ffff:102.87.28.92]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 0000000000103951.0000000063E8C16B.00001412; Sun, 12 Feb 2023 03:37:31 -0700 Date: Sun, 12 Feb 2023 12:33:40 +0300 From: Jean Louis To: Ihor Radchenko Cc: Ypo , Org-mode 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 , Ypo , Org-mode References: <87lelce6iu.fsf@localhost> <87357i9959.fsf@localhost> <877cwse95m.fsf@localhost> <878rh5eqz4.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <878rh5eqz4.fsf@localhost> 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-Flow: FLOW_IN X-Migadu-Country: US ARC-Seal: i=1; s=key1; d=yhetil.org; t=1676198325; a=rsa-sha256; cv=none; b=ECeoA5hrTuMw/8LPDIh9QPeerWm5mcAS/Y8fCWrQdDw+v/n2BfbBltjQhXiHVn94TjFOiM T83wspwJjXQ3OwFKIAwdLPYnatHTmx9ttdUQcGBBfd2SVpaH87cvklXy1jlJBcOtRpab29 QlAMNmKRUKzDy1g/8Q61F6DXr+KXjYzKMr+7NuE66M29V8Z69epJ6fLi/k7jov0o6le1Vp FLwMEzjRu05jL8goznOC+SkAxHZzMDsZAy2JQM1+BQ/kSwg86SiBx+0QkE/f31suFAGIQD rCk3zIyNd2WbFl7K07986Mq+BC2MVIYOWmcLm1HJMGVz7cV5anqhDJtFY/XMXA== 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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1676198325; 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=r3VOJyQAu94JuE/fTJfjwFlwIgNb/zq/ykFAst1YgIM=; b=cRDiKOiEwRKPepo0tJY0Tqt2T5sVBJl1zmsIZ+9loLeYxM/kB6mFTNF3gHusMAJpiYFs9M rrAfX5/TfmMtPhAJG2gjMC8LYvVZVDl1itavOsmxfenr7V+hamIDQxAaMQEcSsaeu8xqr5 OMR1SBrRf1XpVr/RBbl8vUBykHtRhpEE4RUud+aw+vkk7sZeM5pYPQpejsVC1z7XWdVeGR fp4koLx9iLXmZDM+PY1R9kQA7QOWAIoelFomaKxijT5qioYgtKscExwCmvRvQAQve77O4h Ad9oKkiYcenTthFu18g/zcLhPowLLewSNAvBv9qA+Yi1xEBvJC0XIwd8Mkec8w== X-Migadu-Queue-Id: C8FC81AD1E 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-Scanner: scn0.migadu.com X-Migadu-Spam-Score: -3.72 X-Spam-Score: -3.72 X-TUID: Dnqru2dNPRtf * Ihor Radchenko [2023-02-10 13:48]: > Jean Louis writes: > > > If you start adding in Org "fixed" time with UTC offset, that is a new > > type of timestamp, as it is not common in world. > > It is how ISO8601 defines offsets. - did you say you wish to represent time with UTC time zone by using UTC offset? - and I said, UTC time is always without offset, and if any is represented then it must be +00 - and now you say that ISO8601 defines offsets... sorry, you are confusing me and readers. Please see here: https://en.wikipedia.org/wiki/ISO_8601 on right side, there is representation of UTC time: Date and time in UTC 2023-02-12T06:45:15+00:00 2023-02-12T06:45:15Z 20230212T064515Z Do you see? There is no offset larger or smaller than zero. We were discussing of a time stamp at @UTC time zone with offset! That type of a timestamp does not exist. What exists with positive or negative offset is timestamp with time zone other but UTC. But not with UTC. If you do introduce positive or negative offsets at UTC time zone, you are introducing something new in Org. It is not necessarily bad, but IMHO you will create more confusion, for no good reason. > > Here is suggestion: > > ------------------- > > > > 1. Convert local time timestamp to UTC > > 2. Add 10024 hours > > 3. Provide timestamp in UTC > > This will involve converting time, which is prone to errors. I still > think that sometimes it is more convenient for human to use familiar > time zone and fix the offset for future. Your answer is not related any more to @UTC time you were mentioning as now you are using "familiar time zone". I said, there is no offset representation with UTC time but +00. But it can be with other time zones. However, when you say "fix the offset for future" that does not work. If you do specify time zone, you are fixing it by time zone, and not by UTC offset, because it is less likely that the time zone definition changes, but UTC offset can change easier. The UTC offset is property of the time zone. The future time zone definition will know what is it's UTC offset. You can introduce something new in Org and say "This is fixed UTC offset in time zone @ABC" but that way you are confusing yourself and future programmer and users, as it does not comply to already accepted international standards. iCalendar proposes different way of representation of time in future,haw that is, it could be UTC time in future, or it could be date, time and time zone. Using UTC offset for future is redundant, as in present time when you are writing future time stamp, you cannot know the future UTC offset. > > Also look at this reference: > > https://icalendar.org/iCalendar-RFC-5545/3-3-5-date-time.html > >i > > ,---- > > | The form of date and time with UTC offset MUST NOT be used. For > > | example, the following is not valid for a DATE-TIME value: > > | > > | 19980119T230000-0800 ;Invalid time format > > `---- > > > As with the above format, author would maybe think it is alright, but > > in general it is confusing. If author wish to specify UTC time, then > > no offset shall be used. > > icalendar is _not_ the only time spec around. We can take it into > account, but I do not see any reason to follow it blindly. How about finding reasons why iCalendar specifies it that way? And then deciding if those reasons, not specification literally, should be followed? > Reading the linked RFC spec, I did note that the motivation for the time > format used in calendar is mainly scheduling meetings for people > residing in different time zones. And I think that is what we are talking about, about conclusive time representation in cases where Org users need it. If meeting or not, that is something for users to decide. Important is only to define the types of time stamps, and then let users use it. Goal is to improve Org timestamps so that Org get feature of conclusive time representation. That means to me, that inconclusive, like floating timestamps can be left how they are, only new are added. For past time representation is best using UTC timestamp, as such can easily be converted to local time. But how? Using overlays? Or updating time stamps in buffer? Or using updated local time timestamps in exports? There is that time stamp for future, if it should not be floating or non-conclusive, then you use date, time and time zone. You insist on "fixing UTC time offset for time zone", but I do not understand that reasoning, as it is contradictory to time zone database use per se. > I can see how the icalendar format is reasonable within that > specific purpose. I cannot see why Org timestamps should be limited > to meetings. "Meeting" is not for Org to specify, that is for user to specify what it is. It need not be meeting, any future representation is quite different from past. Past timestamps are more conclusive, than future. Past time zone databases already exists, TZ database is rarely updated with past time zones, they are already there. Only for historical purposes past time zones may be updated. But very rarely. You have got past, and future. Any non-floating "present" timestamp is already past in the moment it is created. "Meeting" is not time type of a timestamp. It is action to take place. That action can be anything, leave that to users. I am using various actions, like "call", "marketing campaign", "directory action", "case", "action", "follow-up", "task", "plan", "meeting", and various others. And not forget, "timestamp" is by computing definition always past. In Org we are trying to inject future timestamps by thinking it is "timestamp" while in other computing subjects timestamps is by rule always past and not future. References show that future shall be sheduled by using date, time and time zone or by using UTC plainly. Problem is how to represent or diferrentiate future from past in Org type of a timestamp. This would be alright for me: <2023-03-10 Fri 10:24 @Europe/Berlin> One would need to provide algorithm to Org as to avoid placing invalid timestamps in future, and in future, Org would know how to ask TZ database to derive the UTC offset. > Note that the idea with (optionally) providing two time zones/offsets is > also coming from a time spec in > https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/ Please note: - that document speaks of timestamps in it's definition, that means "timestamp is represntation of past time". - It references: https://www.rfc-editor.org/rfc/rfc3339 if you read introduction, it says "when representing and using date and time in Internet protocols" (Org is not Internet protocol), and then "There are many ways in which date and time values might appear in Internet protocols: this document focuses on just one common usage, viz. timestamps for Internet protocol events" (Org is not Internet protocol event) - then your referenced document says "This document defines an extension syntax for timestamps as specified in [RFC3339] that has the following properties" - then your above referenced document further says "This document does not address extensions to the format where the semantic result is no longer a fixed timestamp that is referenced to a (past or future) UTC time. For instance, it does not address: * Future time given as a local time in some specified time zone, where changes to the definition of that time zone (e.g., a political decision to enact or rescind daylight saving time) affect the instant in time corresponding with the timestamp." Conclusion is that your reference is only partially relevant, as you may use it as guide for past timestamps, but not as guide for future time representation. > Considering that the idea with "!" has been independently proposed > within the current discussion, I assess that allowing two time zones ca > be useful. After I told you above, maybe you should re-consider how did you draw those conclusions. I do not see how your idea is analogous to what documents speak about. > Please remember that this format is optional. If it is not useful for > your use cases, feel free to specify a single time zone. For myself is less important, I can create timestamps in Org how I wish and want. In general for future, I am using structured time representation, same thing what is recommended internationally. Time zone nil Start Date and Time "2023-02-10 06:31:57.919956+03" End Date and Time nil - begin timestamp is with time zone representation, +03, it is only represented that way, but that is UTC time. - only if there is time zone defined, then the UTC offset will be disregarded, and new time calculated by using the time zone's definition and it's UTC offset. That is same thing as iCalendar, or any other software that knows how to deal with time, I just coupled it together and made conditional. My Org use is very structured. I use Org or any markup with properties. And I mix markups like Org, LaTeX, Asciidoc, all in one document. In same way my timestamps are separated from Org objects. Thus for this representation: Time zone nil Start Date and Time "2023-02-10 06:31:57.919956+03" End Date and Time nil That is UTC time and it will be displayed in my local time zone as: 2023-02-10 06:31:57.919956+03 but if I would be in Europe/Berlin time zone, it would be displayed as: 2023-02-10 04:31:57.919956+01 How is Org going to display a timestamp in local time when it is stored in UTC time? It needs either re-writing of a buffer, or temporary preview, or conversions during export. And when my time representation has any time zone, then it is displayed in that time zone: Time zone "Asia/Kuching" Start Date and Time "2023-02-10 06:31:57.919956+03" End Date and Time nil In this case, it will be represented in my local time, but this way: 2023-02-10 11:31:57.919956+03 In my case where I keep timestamps as properties separate from Org objects, it is very easy to get such representations: SELECT CASE WHEN hyobjects_timezones IS NULL THEN hyobjects_date ELSE hyobjects_date AT TIME ZONE hyobjects_timezones END FROM hyobjects WHERE hyobjects_id = 79134; As I rely on PostgreSQL database and their authors, and it spares me programming efforts tremendously. There are many use cases where past representation should NOT be represented with UTC time. Let me remind you that those documents were referring mostly to Internet time protocols, not to human representation of time. When person is born, that person knows the date, but the date is tied to location. Thus representing birth date and birth tim with UTC time is of no use. Hospital will tell it was date of 2023-02-12 and 06:00 o'clock. The time zone is forgotten in such representations, only local people could derive the time zone. Practically UTC time in such representation is only confusing. It may be represented in UTC time, but what really matters is not the UTC time but local time. So local time must be seen with eyes, even if stored with UTC time. For this specific birth date case, I always write time with time zone. That means that UTC time is not to be seen or calculated, but only the date, time and time zone information. There are other cases where past time is practically better represented with the time zone. For future time, it is alright for me personally to specify it with the UTC time if such future moments are not really too far in future, as it is unlikely really that my work. Though if there are multiple people involved, then I have to represent it better, and have to say about the time zone. I am choosing the time zone by using completion. If you need this way of completing, let me know, I can provide the list of time zones for purposes of completion in Org. Here is video of how I select time zones: https://gnu.support/images/2023/02/2023-02-12/2023-02-12-11:05:15.ogv In my opinion people should be given the extended timestamp function in Org where they may choose the time zone. - no C-u prefix, interactive selection: <2023-02-12 Sun> - with C-u prefix, interactive, with time: <2023-02-12 Sun 11:09> - with double, C-u C-u, prefix, non-interactive with time: <2023-02-12 Sun 11:10> - but then I do not know what with 3 times C-u, some of those prefixes could be used to let user choose the time zone > >> I would like to remind you that timestamps are not necessarily used for > >> meetings. And not always shared with other people. > > > > Ok, and I have asked you to provide practical examples. > > And I did, in one of the previous replies - scientific experiment. > Another example can be solar eclipse. Thank you, that is good. I have provided examples myself too in this email. As you say, solar eclipse is future time event that in my opinion could be represented with the UTC time and displayed to users in their local time. > > Timestamps for past time, like for logs, I always store as UTC time in > > database, with time zone (which does not mean that time zone is > > stored, but displayed in local time zone). > > For Org, the aim is not to rely solely on programmatically calculating > time in current time zone. It should be possible to create timestamps > readable in raw text. UTC may be readable for some people, but not for > others. Of course, you can put UTC timestamps in your files, if you > prefer. But more general timestamp format should permit different use > cases. I totally agree and that is reason why I am writing, I agree it is good for human to have it readable. > > 4. Hypothetical example of clear timestamp for future: > > [2024-02-04 12:00! @-08,America/Vancouver] > > where the time would be stamped with "!" and that would mean that in the time zone, meeting is at 12 o'clock. > > It would assume that UTC offset can change in future, but 12:00 clock would be authoritative time for future. > > This is ambiguous. 12:00 which time zone? GTM+08? America/Vancouver? The sign "!" is telling "use time, not offset as authoritative". I do not say you should implement it this way, but I am saying it is wrong putting both the time and offset for future time, while you will not know the future offset with certainty. It is not good specifying something in Org program and not clearly giving it to user what is authoritative. It is either the UTC time, or date, time plus time zone. It is not ambigious, it is example that remedies your ambigious example. You said: [2024-02-04 12:00 @-08,America/Vancouver] -- would be counted with fixed UTC offset. So fixed from what? Fixed from time zone America/Vancouver? Fixed form time represented 2023-02-04 12:00? When those parts are separate fields, picture becomes clear: Time zone "America/Vancouver" Start Date and Time "2023-02-04 12:00:00+03" End Date and Time nil >From this time stamp, user seeing it in plain text, cannot know if Org program means that time 12 o'clock is authoritative or that some "fixed offset" is used: [2024-02-04 12:00 @-08,America/Vancouver] - you said, you wish to use "fixed offset" from UTC, but than if it is fixed, you better use UTC straight, and not wrong representation. It is wrong because it is not ordinary. It is either time zone which will tell what is offset in future, or it is UTC time which has no offset. - it is not visible in the time representation that you mean "fixed offset", because traditionally offsets are calculated from time zone database, and not from past representation! - traditionally UTC offset is used with local time in order to calculate what is UTC. 12:00 -08, means 04:00 UTC time. - you have introduced confusion, telling that you wish to represent time also with @UTC time zone but with offset, that is contradictory. - OK fine, if I assume that you wish to use "fixed UTC offset in future", that means you contradict to time zone definitions, you do not even need the time zones! [2024-02-04 12:00 @-08] would mean that UTC time is 20:00 o'clock, and that is UTC time. Why do you need time zone if you wish to say that it is fixed UTC offset? Time zone is used for reason that UTC offsets are not fixed and we have to derive it from their definitions. In general I see you have got it messed up with introduction of: 1. Timestamps @UTC time zone with UTC offsets as they are contradictory to international standards and agreements of time representation. 2. Timestamps with "fixed UTC offset" where you specify time zone, it is contradictory. Sure you need not follow international recommendations for future events, but that will not make Org more useful in that regard of time representation. The GMT-08 time zone you mentioned is not authoriative, I could say it is supplementary. Can you choose GMT-08 by using `tzselect' command? Wonder why... [2024-02-04 12:00! @-08,America/Vancouver] is not ambigous, because it says "America/Vancouver" and has "!" to indicate that 12 o'clock is authoritative time. I made this only hypothetically for you to understand that people will not understand the difference by looking into text like this: [2024-02-04 12:00 @-08,America/Vancouver] where you said that "this is fixed UTC offset", as one cannot derive from text alone what you mean! But this way it can be derived eventually: [2024-02-04 12:00! @-08,America/Vancouver] -- it means 12 o'clock at America/Vancouver time zone in future, UTC offset at time point of planning was -08, but is disregarded as America/Vancouver time zone in future must be consulted and UTC offset how it will defined in future must be used as authoritative. [2024-02-04 12:00 @-08!,America/Vancouver] -- it means it MUST be -08 offset from time 2024-02-04 12:00, but that would indicate UTC time, so it is useless and confusing to mention "America/Vancouver" as: [2024-02-04 12:00 @-08!] would be enough as that would be UTC time, but nowhere is written it is UTC time, it becomes consuing because ordinary time representation is not represented with UTC offset without time zone. Then it would be better: [2024-02-04 04:00 @UTC] as that becomes clear. The time zone database defines everything. Dwell inside of it. Resarch it. Do not create new types of time representation. In case of political changes, the time zone database will again re-define it, so that local time of that representation can be displayed with accuracy. > >> > Maybe this way (hypothetically): > >> > > >> > [2024-02-04 12:00 @-08, America/Vancouver/UTC-FIXED] > >> > > >> > as that way you would give signal to program that you want UTC fixed > >> > time in future, and not 12:00 o'clock necessary. > >> > >> I am sorry, but I don't understand what you mean by UTC-FIXED. > > > > You mentioned it, you wish to have offset and to remain UTC fixed. > > > > And UTC is not fixed, it is either UTC without offset, or time zone > > with UTC offset. > > > > But if you do wish, you have to make "tag" somehow, for computer > > program to know what you mean, "UTC-FIXED" is only hypothetical tag. > > Sorry but I still don't understand. > For me, -08 is GMT+08 nautical time zone. Short form. > America/Vancouver is a time zone. > What is America/Vancouver/UTC-FIXED? It is my attempt to help you understand that time representation type is not visibl from the timestamp, for the reason that you introduced 2 different time representation types, you introduced: - timestamp @UTC time zone with UTC offset, this does not exist anywhere, only in your idea so far, and I hope it will never be implemented, and if it does get implemented I have to file bugs on it - timestamp with time zone other but UTC where you are talking about "fixed UTC offset" which is known that it is not fixed, whereby time zones are used to derive that future UTC time offset. You can fix it for past, not for future. - thus "UTC-FIXED" is only a different "tag" on the timestamp, to make it hypothetically clear in plain text what you really mean - you forgot that user cannot see your intention from [2024-02-04 12:00 @-08, America/Vancouver] in case where you say "UTC offset is fixed" - what if I as user think that is 12 o'clock in America/Vancouver time? - and you think as programmer "This is UTC fixed offset", but where is designation in that text that it is so? - I provided examples how to designate it: 1. [2024-02-04 12:00 @-08!, America/Vancouver] -- means your imaginary UTC fixed one (I hope you will understand and drop it), this is same as 20 o'clock UTC time, why do you show America/Vancouver? Show UTC only. 2. [2024-02-04 12:00! @-08, America/Vancouver] -- means 12 o'clock at America/Vancouver time, no matter the offset. Original offset was -08, but new offset in future could be something else and must be derived from America/Vancouver time zone. 3. [2024-02-04 12:00 @-08, America/Vancouver/UTC-FIXED] is same as example number 1, just with different tag. 4. Do not do that in 1 or 3, that is not what software does. It is new type you are trying to implement because you think with best intentions, but to me is obvious that you have to research it more. > >> It is sometimes easier to define UTC time +offset instead of doing an > >> extra conversion in your head. > > > > I hope you understood the difference. > > > > Providing UTC time plus some offset is inconclusive. It is idea that > > is not aligned with what international community is doing. > > > > Provide UTC time. > > > > Or provide time zone plus UTC offset. > > > > Your idea as such is alright, but is individual, and it has to be > > coordinated with what other programs are doing. Otherwise it become > > confusing. > > > > Remember the reference on iCalendar, "not do do that". > > > > iCalendar provides either UTC time, or date, time and time zone. > > iCalendar is not the only source of truth. The suggested offsets are > what ISO8601 defines. Just that you did not use ISO 8601 principles. You mixed something up. Where does ISO 8601 advises using date, time, with time zone being UTC by using UTC offset other but zero? Show me one example. I have shown you on Wikipedia example of ISO 8601 timestamp by using UTC time. There is no offset. Timestamp stored in computers is mostly stored in UTC time. Then UTC offset is shown only to user looking at it in local time or different time zones. Read here: https://en.wikipedia.org/wiki/ISO_8601#Coordinated_Universal_Time_(UTC) ,---- | If the time is in UTC, add a Z directly after the time without a | space. Z is the zone designator for the zero UTC offset. "09:30 UTC" | is therefore represented as "09:30Z" or "T0930Z". "14:45:15 UTC" would | be "14:45:15Z" or "T144515Z". `---- Thus when representing UTC time, do not use UTC offset. That will confuse people and is what I am talking about "the new Org time type representation". Read here: https://en.wikipedia.org/wiki/ISO_8601#Time_offsets_from_UTC ,---- | The UTC offset is appended to the time in the same way that 'Z' was | above, in the form ±[hh]:[mm], ±[hh][mm], or ±[hh]. | | Negative UTC offsets describe a time zone west of UTC±00:00, where the | civil time is behind (or earlier) than UTC so the zone designator will | look like "−03:00","−0300", or "−03". `---- It EITHER -- OR condition. It is either UTC time, OR time with UTC offset, because UTC time could only be represented with zero offset. For that reason I believe "Z" is used for UTC time. Then read examples of UTC offsets: ,---- | The following times all refer to the same moment: "18:30Z", | "22:30+04", "1130−0700", and "15:00−03:30". Nautical time zone letters | are not used with the exception of Z. To calculate UTC time one has to | subtract the offset from the local time, e.g. for "15:00−03:30" do | 15:00 − (−03:30) to get 18:30 UTC. `---- You mentioned ISO 8601, and I also wish to put your attention on it, so we agree both that the time representation should be aligned with what is commonly used in ISO 8601. Right? Only that I do not agree that you are interpreting it right, for reason that you use date, time, UTC negativ/positive offset at UTC time zone. UTC offset at UTC time zone is zero. Nothing else, never. > iCalendar explicitly disregards the fixed offsets for some > iCalendar-specific reasons. It is iCalendar that is not being > aligned with more common standard. It is. Your interpretation is not. > >> > Then it becomes clear that it will be the UTC offset in future with > >> > assumed mentiond time zone. > >> > > >> > But if you mix UTC offset, plus the time zone for future, that makes > >> > little sense, unless you introduce some tags that timestamp is > >> > recognizable as using UTC time, or that it uses date/time and time > >> > >> The problem being addressed with @+08,!Asia/Singapore is possible future > >> change in time zone. > > > > That problem is solved, if you use TZ database: > > > > - in case of change of time zone, the TZ database will provide future > > adjustment, there may be new name of new time zone. > > > > - in case of change of UTC offset, the TZ database in future will know > > it. > > Your statement is true only when TZ database is guaranteed to be > up-to-date. It is not always the case. Consider opening an Org document > on machine with out-of-date TZ database. Of course. And you are not making it compatible to outdated TZ databases! You are making it compatible to present and future TZ databases! In general, you can also leave org with floating timestamps, as very few people will get affected, if at all. Most of professiona people cannot use Org for meeting and appointments, and collaborative time management! Org is single user application. What we are talking here about is trivial when MySQL or MariaDB or PostgreSQL is used. Majority of ERP software runs on such databases, they use functions that matter. Org is not for that, and will never be without some serious and striking integration efforts. It means, do not strive for absolute accuracy. Strive for simplicity. > > I will never miss the meeting provided program consults TZ database. > > You will not. But I can see myself missing the meeting and assuming the > time "as usual". Of course everything in our life is conditional. Maybe the planet will stop moving, it must stop and disintegrate at one point of time in future. We speak of reality that is in present time, TZ database is being updated, and is our current reality. Time Zone Database: https://www.iana.org/time-zones I also do not consider it "authoritative" as it is in hands of United States. In case of international war, they can corrupt it, and corrupt other countries time. It is not something "universally" accessible, it relies on consensus, and is not under our people' control. It has to be updated with political statuses. Too many conditions! It is constantly updated work and effort. > > But if I have 2 timestamps, that is different situation. > > > > You need no UTC offset for future time representation. > > > > Also good to read: > > https://engineering.q42.nl/why-always-use-utc-is-bad-advice/ > > > > Also good to read: > > https://swizec.com/blog/saving-time-in-utc-doesnt-work-and-offsets-arent-enough/ > > The second link illustrates exactly UTC offset + also time zone name. > Similar to what I proposed. Remember, you started by showing UTC offset with UTC time zone, and only for that specific case I told you that is not how it works and how time should be represented. I think you are referring to following, do you? ----------------------------------------------- From: https://swizec.com/blog/saving-time-in-utc-doesnt-work-and-offsets-arent-enough/ ,---- | "You have an appointment today at 3pm" is tricky. Your server runs in | UTC (usually), the user is who knows where. Their 3pm is not your | server's 3pm 💩 | | One solution is to save time with a UTC offset. | | Like this: | | 2022-03-09T15:00:00-08:00 | | Instead of Z for zulu time, we have an offset that says this time is 8 hours behind UTC. At 3pm. | | Now your server understands the user's intention of 3pm and the exact | point in time for UTC. Fantastic. `---- That is his idea! But that idea is incorrect, I am sorry as I did not refer to that idea, but other parts on article. That guy never implemented that idea for reason that it simply does not work! There is no such type of time types in the PostgreSQL or MySQL database. You can only get the representation by program. Example: #+BEGIN_SRC sql :engine postgresql :exports results :host localhost :cmdline :database admin CREATE TABLE example (time TIMESTAMP WITH TIME ZONE); #+END_SRC #+RESULTS: | CREATE TABLE | |--------------| #+BEGIN_SRC sql :engine postgresql :exports results :host localhost :cmdline :database admin INSERT INTO example (time) VALUES ('2023-02-12 12:00-03:00'); #+END_SRC #+RESULTS: | INSERT 0 1 | |------------| #+BEGIN_SRC sql :engine postgresql :exports results :host localhost :cmdline :database admin SELECT * FROM example ORDER BY time DESC; #+END_SRC #+RESULTS: | time | |------------------------| | 2023-02-12 18:00:00+03 | | 2023-02-12 18:00:00+03 | Or we try without time zone? #+BEGIN_SRC sql :engine postgresql :exports results :host localhost :cmdline :database admin CREATE TABLE example_without (time TIMESTAMP WITHOUT TIME ZONE); #+END_SRC #+RESULTS: | CREATE TABLE | |--------------| #+BEGIN_SRC sql :engine postgresql :exports results :host localhost :cmdline :database admin INSERT INTO example_without (time) VALUES ('2023-02-12 12:00-03:00'); #+END_SRC #+RESULTS: | INSERT 0 1 | |------------| #+BEGIN_SRC sql :engine postgresql :exports results :host localhost :cmdline :database admin SELECT * FROM example_without ORDER BY time DESC; #+END_SRC #+RESULTS: | time | |---------------------| | 2023-02-12 12:00:00 | As you can see, you and that guy, you got similar idea, but that does not exist in software. What can be done is to record time with offset as text. Or it can be recorded as date, time without time zone, without offset, but with offset being separate. However, I repeat, that is totally out of what other software and other programmers do. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/