Could it be reasonable to collect the hypothetical cases where relative timestamps would be used? So, alternatives and solutions could be evaluated more easily. For example: | External Input                                          | User's input                     | Org output                             | Agenda output (local time) | Org time storing     | |---------------------------------------------------------+----------------------------------+----------------------------------------+----------------------------+----------------------| | Meeting at 09:37:54, 28 February 2023, in Foz do Iguaçu | [2023-02-28 ma. 09:37 @UTC-3]    | [2023-02-28 ma. 09:37 @UTC-3]          | [2023-02-28 ma. 13:37]     | 20230228T12:37:54,68 | | Same case as above                                      | [2023-02-28 ma. 09:37 @timezone] | [2023-02-28 ma. 09:37 @UTC-3,timezone] | [2023-02-28 ma. 13:37]     | 20230228T12:37:54,68 | | Party at my home, tomorrow                              | [2023-02-13 lu. 14:15]           | [2023-02-13 lu. 14:15 @UTC+1,timezone] | [2023-02-13 lu. 14:15]     | 20230213T13:15:54,68 | - I didn't expect this: it is more difficult for me to find the timezone, and to write it in the correct format, than to find the UTC offset. - Maybe org output should always show the time zone, since for calculations - Should convert show every timestamp timezone, so we know local timezone is correct? - Sorry for the table format, I don't know how to export it from orgmode to thunderbird's mail editor. > ------------------------------------------------------------------------ > * Max Nikulin [2023-02-11 07:47]: > >/On 10/02/2023 10:29, Jean Louis wrote:/ > >/> 2030-02-09 12:00 -08 @UTC -- this time CANNOT be said to be "fixed/ > >/> UTC"/ > >// > >/I do not see any reason why obviously invalid timestamp draws so much/ > >/attention./ > >// > >/Resolution may be rather concise: behavior is *undefined* since field > values/ > >/are mutually inconsistent. Perhaps implementation may prefer to treat > it as/ > >/2030-02-09T12:00:00-0800 discarding UTC as time zone specifier. > `org-lint'/ > >/should issue a warning requesting a user action./ > > Thank you! > > I have demonstrated that Etar application from F-Droid would disregard > what is invalid and basically only enter valid time. Same for Google > calendar, it would disregard invalid timestamp (even though not > represented as above), and it would enter only valid one. PostgreSQL > will "silently" ignore what does not belong to it. > > One can search for "silent" here: > https://www.postgresql.org/docs/current/datatype-datetime.html > > >/Could you explain what is wrong with the following (without timezone)?/ > >// > >/2030-02-09 12:00 -0800/ > >// > >/I consider it as an unambiguous equivalent of 2030-02-09T20:00:00Z > that is a/ > >/UTC timestamp./ > > That is not same case as Ihor, when he designated it as > > 2030-02-09 12:00 -0800 @UTC > because there are no offsets @UTC time zone. > > In this different case you wish to say that it is: > > time of 2030-02-09 12:00 -0800 whereby -0800 is UTC offset from floating time > 2030-02-09 12:00, and one can derive UTC time. > > That is totally alright as representation of time. That is how past > timestamps are represented in local time. > > Why not -- you can use it for future. > > I find it less useful for exchange purposes, almost useless, but you > can do. Because if you store time as UTC, you can always see local > time anywhere in the world. But if programmers wish to do that to Org, > okay fine. > > It is different time type representation, that does not exist in ISO > 8601, but why not, you can include it in Org. > > You just be sure that you put a "tag" or such representation that > users will know what is it, even from plain text. > > >/The format with explicit offset may be convenient for a person/ > >/living in an area that *likely* will have -08:00 offset and who/ > >/would like to watch some astronomical event such as lunar eclipse/ > >/and who had a plan to connect to some telescope on the opposite side/ > >/of the globe. Event time will not change if local time changed. Both/ > >/variants 2030-02-09T12:00:00-0800 and 2030-02-09T20:00:00Z may be/ > >/presented as "2030-02-09 12:00" to users./ > > And now you speak of presentation. But then why store it with > 2030-02-09T12:00:00-0800 when you can store it as 2030-02-09T20:00:00Z > and have representation be same "2030-02-09 12:00" to users. > > So that is only addition to programmer. > > Remember that not even databases store the time like that. It is > either UTC time, or date, time, and some time zone stored separately. > > >/If timezone offset is changed both variants will converted to/ > >/"13:00" or "11:00" depending on sign of change./ > > Correct. I understand you want to say that representation of time for > that UTC time zone will be modified depnding of change, and that is > correct. > > >/So the format with offset is human friendly because it gives a hint/ > >/concerning *probable* value of local time still remaining *precise*/ > >/in respect to UTC./ > > This representation of time is human friendly: > 2030-02-09 12:00 -0800 and that is the way how I daily see my > timestamps, like this: 2023-02-12 12:59:52.839773+03 > which does not differ much from that one. > > However, my timestamp is only represented with +03 UTC offset. It is > not stored with UTC offset. > > Storing values is not equal to representing values. > > - In other software values are not stored as "UTC time that has > offset" > > - It is stored as "UTC time" > > - Offset is calculated from time zone and represented to user. > > Of course you need not follow what other software does. > > Though I think you need rather exact designation for users to > unmistakably can understand what you mean with it: > > - Right now when I press C-c . I get: <2023-02-12 Sun> > > - C-u C-c . and I get <2023-02-12 Sun 13:03> > > - Then I can think you (developers) will invent something like: > <2023-02-12 Sun 13:03 @Europe/Berlin> (whereby one has to avoid > invalid time stamps), which is UTC time: 2023-02-12 12:03:00 > > - Then I can think you would invent time stamp which you proposed, > something like: <2023-02-12 12:00 -08:00> which in this case cannot > have day representation, as one cannot know which day is that, > right? > > And in this case that timestamp would mean it is 20:00 o'clock UTC > time. > > And which can be replaced with <2023-02-12 20:00 @UTC> > > I am just not sure if that will be enough human friendly to say: > <2023-02-12 12:00 -08:00> to people, as there is no designation that > it is UTC time, and one cannot use "@UTC" as that would be wrong. > > Maybe designation is not necessary? > > When we consider how good calendars work, they will always ask user > for the time zone. There is settings. > > And then if you write that event is on Sunday 20 o'clock, it will be > considered 20 o'clock at that time zone. > > When you send it, it will be maybe converted to UTC time, but maybe > not, maybe with time zone designation. > > In any case remote user will either get UTC time or date, time with > time zone. > > Getting time representation with offset, to calculate UTC time seem > redundant. > > But why not, it is possible. > > Will you do it, practically implement it? > > >/I find the following as acceptable, but confusing to some degree:/ > >// > >/2030-02-09 12:00 -08/ > >// > >/just because "-08" is currently used in TZ database as time zone/ > >/abbreviation (a string similar to "BST"), not as offset that is > represented/ > >/in wide spread formats as -0800 or -08:00. Unfortunately the latter > causes/ > >/ambiguity in the context of Org./ > > That is why is better not to use TZ time zone abbreviation for future times! > > For past times, is somehow okay. For future no. > > Let me consult the database. > > #+BEGIN_SRC sql :engine postgresql :exports results :host localhost :cmdline > :database rcdbusiness :dbuser maddox > SELECT name, abbrev, utc_offset, is_dst > FROM pg_timezone_names where abbrev = '-08'; > #+END_SRC > > #+RESULTS: > | name | abbrev | utc_offset | is_dst | > |------------------------+--------+------------+--------| > | Etc/GMT+8 | -08 | -08:00:00 | f | > | Pacific/Pitcairn | -08 | -08:00:00 | f | > | posix/Etc/GMT+8 | -08 | -08:00:00 | f | > | posix/Pacific/Pitcairn | -08 | -08:00:00 | f | > > In your example, you should not use time zone abbreviations to say > that it is UTC time with offset. > > Better use accurate offset (which is not UTC offset, as that is changeable). > > This is better if you really wish to designate the time with offset > which represents UTC time: > > 2030-02-09 12:00 -08:00 > > Because you are rounding for no good reason! You have introduced new > type of time storage, which is time with offset representing UTC time. > > While UTC offsets are mostly rounded, you are introducing not the UTC > offset, but "offset". > > That means that following is also just fine: > > 2030-02-09 11:47 -08:12 > > Which is not common. But you insist on using time with offset, that > represents UTC time, however, then you should not be using "UTC > offsets" for such representations, but leave to users what "offset" to > add or deduce, for UTC calculation. > > I am against such storage, and representation, but either: > > - as UTC time, without offset > > - or as date, time, time zone, as UTC offset can be calculated in future time > points > > But we can see that Org is different case, it is textual, not database. > > However, this time: <2023-02-12 13:29> was always considered floating, > and then by changing anything it can become [2023-02-13 Mon 13:29], > the day is "added" automatically. > > So one needs some "tag" for time represented as UTC time but with > offset, like [2023-02-13 13:29 @TO-UTC -08:00] > > it cannot be "@UTC" as that is time zone. You have to invent how to > represent it, that is unmistakable to other representations. > > -- > Jean > > Take action in Free Software Foundation campaigns: > https://www.fsf.org/campaigns > > In support of Richard M. Stallman > https://stallmansupport.org/ > > > *From*: Jean Louis > *Subject*: Re: [POLL] Proposed syntax for timestamps with time zone > info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps > and org-agenda) > *Date*: Sun, 12 Feb 2023 13:32:21 +0300 > *User-agent*: Mutt/2.2.9+54 (af2080d) (2022-11-21) >