emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
@ 2023-02-04 18:59 ypuntot
  2023-02-04 19:45 ` Jean Louis
  2023-02-05 17:04 ` Max Nikulin
  0 siblings, 2 replies; 90+ messages in thread
From: ypuntot @ 2023-02-04 18:59 UTC (permalink / raw)
  To: Org-mode

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

Great link!
https://spin.atomicobject.com/2016/07/06/time-zones-offsets/

"Given a local time and an offset, you can know UTC time, but you do not know which time zone you’re in (because multiple timezones have the same offset)."

So, given a time zone you can know the offset (Google it, for example)..
Then, given the time zone and the local time, you can know UTC.
If orgmode gets the UTC there is not ambiguity.

But, that would mean that the offset related to the different time zones must be downloaded and updated from some site.
As you said before, that offset can change. For example, peninsular Spain has the same time as Berlin, but as this doesn't make much sense, it could change, so updates would be necessary.

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

^ permalink raw reply	[flat|nested] 90+ messages in thread
* Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
@ 2023-02-12 13:27 Ypo
  0 siblings, 0 replies; 90+ messages in thread
From: Ypo @ 2023-02-12 13:27 UTC (permalink / raw)
  To: Org-mode

[-- 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 --]

^ permalink raw reply	[flat|nested] 90+ messages in thread
* Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
@ 2023-02-04 21:38 Ypo
  2023-02-05  3:12 ` Max Nikulin
                   ` (2 more replies)
  0 siblings, 3 replies; 90+ messages in thread
From: Ypo @ 2023-02-04 21:38 UTC (permalink / raw)
  To: Org-mode

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

> Great link!
> https://spin.atomicobject.com/2016/07/06/time-zones-offsets/
>
> "Given a local time and an offset, you can know UTC time, but you do 
> not know which time zone you’re in (because multiple timezones have 
> the same offset)."
>
> So, given a time zone you can know the offset (Google it, for example)..
> Then, given the time zone and the local time, you can know UTC.
> If orgmode gets the UTC there is not ambiguity.
>
> But, that would mean that the offset related to the different time 
> zones must be downloaded and updated from some site.
> As you said before, that offset can change. For example, peninsular 
> Spain has the same time as Berlin, but as this doesn't make much 
> sense, it could change, so updates would be necessary.
I have been thinking about how I would use this feature. So use cases 
appeared, which arose some doubts about how to use this feature, and an 
opinion for the Poll surged:

If I wanted to assist to a "Mastering Emacs book club" meeting in 
America/Vancouver, while living in Spain: Doubt: Should I use local time 
of America/Vancouver to schedule the meeting?. Like: [2024-02-04 12:00 
@America/Vancouver] (I don't like space before the @, for the Poll).
1. Doubt: I suppose my agenda timestamp would be: [2024-02-04 do. 
21:00]. (Spain local time). Correct?
2. If I went on vacation to Brasília, my agenda timestamp should change 
to: [2024-02-04 do. 17:00]. (Brasília local time).
    Doubt: How must the local time zone be updated to get that timestamp 
changed?
3. Back to Spain, I see that, for political reasons, Vancouver's winter 
time-zone changed from UTC-8 to UTC-9.
    Doubt: How would my tz database be updated?
    Doubt: After updating the tz database, my agenda timestamp would 
change automatically to  [2024-02-04 do. 22:00]. Correct?
4. For the Poll: What would be the expected behavior if we used the UTC 
offset?  [2024-02-04 12:00 @-08,America/Vancouver]
     - We should know beforehand the DST of Vancouver, or there would be 
warnings. It seems more difficult for the user: maybe the "-08," should 
be optional?
     - Case 3: After updating the tz database we would get warnings too. 
To correct those warnings, should the UTC offset be changed manually in 
the timestamp?. If there were 35 meetings in Vancouver throughout the 
year, to change all the UTC offsets could be non trivial for a normal 
user: UTC of the summer and winter would differ.
       [2024-09-04 12:00 @-07,America/Vancouver] should be changed to 
[2024-09-04 12:00 @-08,America/Vancouver]
       [2024-02-04 12:00 @-08,America/Vancouver] should be changed to 
[2024-02-04 12:00 @-09,America/Vancouver]



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

^ permalink raw reply	[flat|nested] 90+ messages in thread
* Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
@ 2023-01-17  3:55 Daryl Manning
  2023-01-17  8:22 ` Tim Cross
  0 siblings, 1 reply; 90+ messages in thread
From: Daryl Manning @ 2023-01-17  3:55 UTC (permalink / raw)
  To: emacs-orgmode; +Cc: rjhorn

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

I'd argue that setting a specific datestamp  and time for DST would mean
that you expected to meet at that specific time and date as per DST. If the
clocks changed you'd be out of luck (that's where I'd argue you'd use a
non-specified timezone for a meeting that re-occurs at 10:05 regardless of
say PDT or PST).

But if this was an issue with a recurring meeting, then when the clocks
changed someone would be out an hour because they had specifically booked
with DST in mind (note: this is more useful than you think - being in
non-DST countries and having scheduled meetings in DST based countries, a
lot of cal applications get this wrong when what I actually want is for
that DST scheduled meeting to now be reflected in my calendar on the fact
they've switched to ST in their time zone - so shifted an hour.).

But I feel this is something that would be for people who need to take
advantage of this. And, more often than not, is a recurring meeting issue
when DST/ST changes occur.

Daryl.


On Tue, Jan 17, 2023 at 3:54 AM Robert Horn <rjhorn@panix.com> wrote:

>
> Ihor Radchenko <yantar92@posteo.net> writes:
>
> > Robert Horn <rjhorn@panix.com> writes:
> >
> >>> 1. Time (YYYY-MM-DD HH:MM) not continuous and may change arbitrarily at
> >>>    certain times a year or in future or in the past:
> >>>    - DST transitions are not stable and change from year to year
> >>>      according to strange rules that may involve Julian dates or
> >>>      counting weekdays
> >>>    - DST transition rules may change over time
> >>>    - The new year day itself is not necessarily fixed (England
> >>>    - Julian/Gregorian transitions happened at different times in
> >>>      different countries
> >>
> >> Note that as a result "time when it happened" has different rules than
> >> "future time when it is scheduled".  There are lots of other times that
> are
> >> scheduled as "future local time, subject to changing DST rules".  This
> >> is particularly tricky for repeating times for regularly scheduled
> events.
> >
> > Not really. Countries may change DST at any moment in future. Or decide
> > to switch calendars (consider countries near the day transition line).
> >
> > And "past local time, according to the DST rules in effect at the time"
> > is also an option that might be useful in certain scenarios.
> >
>
> The issue is clarity of the expected rules for the format.  If I
> schedule a meeting for 10:05 DST, but the rules change so that it is not
> DST at that location at that time in the future, what is the expected
> interpretation?  It could be:
>
>  a) the meeting should be at 10:05 ST, because the intent was to meet at
>  10AM in the then local time.
>
>  b) the meeting should be at 11:05 ST, because the time was chosen to
>  correspond to a particular sun angle.
>
> Getting the rules and explanation clear is the issue.  It's a mistake
> that a great many people make with scheduling meetings.  Those two
> behaviors need different encodings because they behave differently.
>
> --
> Robert Horn
> rjhorn@alum.mit.edu
>

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

^ permalink raw reply	[flat|nested] 90+ messages in thread

end of thread, other threads:[~2023-03-15 14:43 UTC | newest]

Thread overview: 90+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-04 18:59 [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda) ypuntot
2023-02-04 19:45 ` Jean Louis
2023-02-05 17:04 ` Max Nikulin
2023-02-07 21:46   ` Jean Louis
  -- strict thread matches above, loose matches on Subject: below --
2023-02-12 13:27 Ypo
2023-02-04 21:38 Ypo
2023-02-05  3:12 ` Max Nikulin
2023-02-05  9:31 ` Jean Louis
2023-02-05 10:44 ` Ihor Radchenko
2023-02-05 12:12   ` Jean Louis
2023-02-05 13:01     ` ypuntot
2023-02-06 14:15       ` Ihor Radchenko
2023-02-07 21:38       ` Jean Louis
2023-02-06 14:10     ` Ihor Radchenko
2023-02-07 22:19       ` Jean Louis
2023-02-08 10:36         ` Ihor Radchenko
2023-02-10  3:29           ` Jean Louis
2023-02-10 10:48             ` Ihor Radchenko
2023-02-12  9:33               ` Jean Louis
2023-02-12 13:47                 ` tomas
2023-02-14  6:00                   ` Jean Louis
2023-02-14  9:41                     ` Heinz Tuechler
2023-02-14  9:45                       ` tomas
2023-02-14 11:42                         ` Max Nikulin
2023-02-14 15:59                           ` Jean Louis
2023-02-14 16:45                             ` Thomas S. Dye
2023-02-16 14:21                               ` Jean Louis
2023-02-14 16:57                             ` Max Nikulin
2023-02-14 10:45                       ` Jean Louis
2023-03-10 10:46                         ` Ihor Radchenko
2023-03-08 13:30                 ` Ihor Radchenko
2023-03-10  1:37                   ` Jean Louis
2023-02-11  4:44             ` Max Nikulin
2023-02-12 10:32               ` Jean Louis
2023-02-15 15:17                 ` Ihor Radchenko
2023-02-16 15:06                   ` Jean Louis
2023-03-10 10:51                     ` Ihor Radchenko
2023-03-15 14:42             ` Max Nikulin
2023-01-17  3:55 [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda Daryl Manning
2023-01-17  8:22 ` Tim Cross
2023-01-17  9:15   ` Ihor Radchenko
2023-01-17  9:45     ` Tim Cross
2023-01-18  9:15       ` Ihor Radchenko
2023-01-18 11:43         ` Tim Cross
2023-01-18 12:02           ` Ihor Radchenko
2023-01-18 21:16             ` Tim Cross
2023-01-19  5:29               ` Jean Louis
2023-01-19  7:23                 ` Tim Cross
2023-01-19 14:32                   ` Jean Louis
2023-01-19 20:09                     ` Tim Cross
2023-01-19 23:02                       ` Thomas S. Dye
2023-01-19 23:51                         ` Tim Cross
2023-01-20  0:24                           ` Thomas S. Dye
2023-01-20  3:46                             ` Tim Cross
2023-01-20  6:14                               ` Thomas S. Dye
2023-01-27  6:06                                 ` Sterling Hooten
2023-01-27 11:09                                   ` Ihor Radchenko
2023-01-30 11:25                                     ` Greg Minshall
2023-01-31 11:48                                       ` [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda) Ihor Radchenko
2023-01-31 12:19                                         ` Daryl Manning
2023-01-31 12:41                                           ` Ihor Radchenko
     [not found]                                             ` <CAL9aZksf8AGF=dXg0KAtLPyu1ATt1fLpvdsjN6GMCuK2KRQ56w@mail.gmail.com>
2023-01-31 13:33                                               ` Ihor Radchenko
2023-01-31 13:22                                         ` Jean Louis
2023-01-31 13:46                                           ` Ihor Radchenko
2023-01-31 19:59                                             ` Jean Louis
2023-02-01 12:42                                               ` Ihor Radchenko
2023-02-01 15:28                                                 ` Jean Louis
2023-02-01 16:30                                                   ` Ihor Radchenko
2023-01-31 20:12                                             ` Jean Louis
2023-02-01  5:46                                               ` tomas
2023-02-01  7:29                                                 ` Jean Louis
2023-02-01  7:52                                                 ` Tim Cross
2023-02-01  8:32                                                   ` Jean Louis
2023-02-01  8:46                                                   ` Ihor Radchenko
2023-02-01  9:38                                                     ` Tim Cross
2023-02-01 10:15                                                       ` Ihor Radchenko
2023-02-01 14:53                                                         ` Jean Louis
2023-02-01 16:36                                                           ` Ihor Radchenko
2023-02-01 10:46                                                       ` Max Nikulin
2023-02-01 14:43                                                       ` Jean Louis
2023-02-01 16:45                                                         ` Ihor Radchenko
2023-02-02  3:05                                                           ` Max Nikulin
2023-02-02  8:59                                                             ` Ihor Radchenko
2023-02-01 14:38                                                     ` Jean Louis
2023-02-01 16:50                                                       ` Ihor Radchenko
2023-02-01  7:00                                               ` Thomas S. Dye
2023-02-01  7:41                                                 ` Jean Louis
2023-01-31 18:56                                         ` Greg Minshall
2023-02-01 12:48                                           ` Ihor Radchenko
2023-02-01 12:52                                             ` tomas
2023-02-02  4:49                                               ` Greg Minshall
2023-01-31 20:41                                         ` Tim Cross
2023-01-31 23:50                                         ` Samuel Wales
2023-02-01 13:01                                           ` Ihor Radchenko
2023-02-04 22:33                                             ` Samuel Wales
2023-02-04 22:49                                               ` Samuel Wales
2023-02-05 10:38                                               ` Ihor Radchenko
2023-02-01 11:56                                         ` Christian Moe
2023-02-01 12:20                                           ` Ihor Radchenko
2023-02-01 15:41                                             ` Jean Louis
2023-02-02  8:38                                               ` Ihor Radchenko
2023-02-03 11:31                                                 ` Jean Louis
2023-02-04 10:58                                                   ` Ihor Radchenko
2023-02-04 19:32                                                     ` Jean Louis
2023-02-05  9:14                                                       ` Ihor Radchenko
2023-02-02  3:46                                         ` Timothy
2023-02-02  9:12                                           ` Ihor Radchenko
2023-02-02  9:12                                             ` Timothy
2023-02-02  9:20                                               ` Ihor Radchenko
2023-02-02  9:27                                                 ` Timothy

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).