Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ypo <ypuntot@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 10816 bytes --]

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<manikulin@gmail.com>  [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)
>

[-- Attachment #2: Type: text/html, Size: 12451 bytes --]