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

On 10/02/2023 10:29, Jean Louis wrote: https://icalendar.org/iCalendar-RFC-5545/3-3-5-date-time.html , | 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: | | 19980119T23-0800 ;Invalid time format `

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

Jean Louis writes: > Where you Ihor responded with this message: > https://lists.gnu.org/archive/html/emacs-orgmode/2023-02/msg00018.html > >> [2022-11-12 14:00 @UTC+2] >> [2022-11-12 14:00 @UTC-2:30] > >> are also fine within the proposed format. > > I am not sure what did you intend to show,

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

Jean Louis writes: > Discussion started from something like this: > > 2022-11-12 12:00+02 @UTC > > and that is different case, where Ihor was suggesting that: 2022-11-12 > 12:00 is UTC time, not local time, where by +02 is offset (I say not > UTC offset) to be added or deducted on that time.

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

* Ihor Radchenko [2023-03-08 16:29]: > > The UTC offset is property of the time zone. The future time zone > > definition will know what is it's UTC offset. > > UTC offset is indeed a property of the time zone. > However, UTC offset may be a subject of change in some time zones. Yes, and that

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

Jean Louis writes: >> > 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

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

* Ihor Radchenko [2023-02-15 18:17]: > Jean Louis writes: > > > 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. > > I do not recall providing such example. May you point me to the message > where you

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

* Thomas S. Dye [2023-02-14 19:50]: > > What Ihor proposed is time stamp like: > > > > 2023-02-14 Tue 12:00:00 +0800 @UTC > > > > Though I just say when we put "UTC" that means normally "UTC time > > zone" and such has no prefix that is positive or negative, can be > > zero. > > Sigh. UTC is

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

Jean Louis writes: > 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. I do not recall providing such example. May you point me to the message where you saw me writing -0800 @UTC? -- Ihor Radchenko //

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

On 14/02/2023 22:59, Jean Louis wrote: What Ihor proposed is time stamp like: 2023-02-14 Tue 12:00:00 +0800 @UTC I am not sure that combination of +0800 and UTC was intentional. The following is redundant, but there is nothing wrong while offset and time zone identifier are in agreement:

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

Jean Louis writes: * Max Nikulin [2023-02-14 14:45]: On 14/02/2023 16:45, to...@tuxteam.de wrote: > On Tue, Feb 14, 2023 at 10:41:38AM +0100, Heinz Tuechler > wrote: > > Jean Louis wrote/hat geschrieben on/am 14.02.2023 07:00: > > > Then just representation must be clear: @UTC is unclear

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

* Max Nikulin [2023-02-14 14:45]: > On 14/02/2023 16:45, to...@tuxteam.de wrote: > > On Tue, Feb 14, 2023 at 10:41:38AM +0100, Heinz Tuechler wrote: > > > Jean Louis wrote/hat geschrieben on/am 14.02.2023 07:00: > > > > Then just representation must be clear: @UTC is unclear in those > > > >

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

On Tue, Feb 14, 2023 at 10:41:38AM +0100, Heinz Tuechler wrote: > Jean Louis wrote/hat geschrieben on/am 14.02.2023 07:00: [...] > > Then just representation must be clear: @UTC is unclear in those > > cases, but @RELTOUTC would be clear. > > > > @RELTOUTC seems unfortunate, as it states only

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

* Heinz Tuechler [2023-02-14 12:44]: > Jean Louis wrote/hat geschrieben on/am 14.02.2023 07:00: > > * to...@tuxteam.de [2023-02-12 16:50]: > > > On Sun, Feb 12, 2023 at 12:33:40PM +0300, Jean Louis wrote: > > > > * Ihor Radchenko [2023-02-10 13:48]: > > > > > Jean Louis writes: > > > > > > >

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

On 14/02/2023 16:45, to...@tuxteam.de wrote: On Tue, Feb 14, 2023 at 10:41:38AM +0100, Heinz Tuechler wrote: Jean Louis wrote/hat geschrieben on/am 14.02.2023 07:00: Then just representation must be clear: @UTC is unclear in those cases, but @RELTOUTC would be clear. @RELTOUTC seems

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

Jean Louis wrote/hat geschrieben on/am 14.02.2023 07:00: * to...@tuxteam.de [2023-02-12 16:50]: On Sun, Feb 12, 2023 at 12:33:40PM +0300, Jean Louis wrote: * 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

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

* to...@tuxteam.de [2023-02-12 16:50]: > On Sun, Feb 12, 2023 at 12:33:40PM +0300, Jean Louis wrote: > > * 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

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

On Sun, Feb 12, 2023 at 12:33:40PM +0300, Jean Louis wrote: > * 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

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

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   

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

* 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

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

* 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

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

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

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

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. > Here is suggestion: > --- > > 1. Convert local time timestamp to UTC > 2. Add 10024 hours > 3.

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

* Ihor Radchenko [2023-02-08 13:36]: > > Is it Org as program? > > > > Or is it human? > > Both. > > The idea is to ensure exact point of time relative to UTC. > For example, when you want to schedule something exactly 10024 hours in > future, regardless of time zone changes. I got it, thank

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

Jean Louis writes: >> It means "when I scheduled this item, I expected the UTC offset at the >> time of the timestamp to be -08 and remain so. It was motivated by >> America/Vancouver time zone, but if it changes in future, I do not care >> - the scheduled time should remain at specific time

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

* ypuntot [2023-02-05 16:03]: > For the Poll, the Jeans proposal would be to introduce manually: > [2024-02-04 12:00 @America/Vancouver] I never recommend or recommended to anybody, ever, to make timestamps manually. That is for computer to make it right. For human, that is to use calendar.

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

* Max Nikulin [2023-02-05 20:06]: > On 05/02/2023 01:59, ypuntot wrote: > > Then, given the time zone and the local time, you can know UTC. > > If orgmode gets the UTC there is not ambiguity. > > Mapping from local time to UTC may be ambiguous, so mapping from local time > to time zone offset

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

* Ihor Radchenko [2023-02-06 17:11]: > Jean Louis writes: > > > * Ihor Radchenko [2023-02-05 13:45]: > >> [2024-02-04 12:00 @-08,America/Vancouver] will use fixed -8 offset > > > > What does that mean practically? Provide example for better > > understanding. > > It means "when I scheduled

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

ypuntot writes: > For the Poll, the Jeans proposal would be to introduce manually: > [2024-02-04 12:00 @America/Vancouver] > And org to convert it into: > [2024-02-04 12:00 @-08,America/Vancouver] > ? Depends on context. We are not really discussing what kind of format will Org use by default.

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

Jean Louis writes: > * Ihor Radchenko [2023-02-05 13:45]: >> [2024-02-04 12:00 @-08,America/Vancouver] will use fixed -8 offset > > What does that mean practically? Provide example for better > understanding. It means "when I scheduled this item, I expected the UTC offset at the time of the

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

On 05/02/2023 01:59, ypuntot wrote: Then, given the time zone and the local time, you can know UTC. If orgmode gets the UTC there is not ambiguity. Mapping from local time to UTC may be ambiguous, so mapping from local time to time zone offset may be ambiguous as well. The extreme case is

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

For the Poll, the Jeans proposal would be to introduce manually: [2024-02-04 12:00 @America/Vancouver] And org to convert it into: [2024-02-04 12:00 @-08,America/Vancouver] ? Ihor's would add the option to get warnings, in case tzdata changes, when that timestamp is generated? [2024-02-04 12:00

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

* Ihor Radchenko [2023-02-05 13:45]: > [2024-02-04 12:00 @-08,America/Vancouver] will use fixed -8 offset What does that mean practically? Provide example for better understanding. - The UTC offset is not certain to remain fixed in the future. - If you do not have the time of creation of the

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

Ypo writes: > 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

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

Samuel Wales writes: > On 2/1/23, Ihor Radchenko wrote: >> the best we can do is minimizing the breakage when designing the new syntax > > as a small nit [followup is not needed as i do not want to distract > from the big boys talking about quantum dst on pluto for timestamps > with [axial

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

* Ypo [2023-02-05 00:41]: > 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,

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

Jean Louis writes: >> It is a correct TZ value 路 > > Time zone value? TZ environment variable value -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at

Re: [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 22:01]: > 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)." Exactly. > So, given a

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

* Ihor Radchenko [2023-02-04 13:58]: > I used "UTC+2" because it is how offsets are often represented. > For example, https://time.is/London is displaying the following: > > Time in London, United Kingdom now > ... > Time zone > - Currently Greenwich Mean Time (GMT), UTC +0 >

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

On 05/02/2023 04:38, Ypo wrote: 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

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

tldr: carry on. :] On 2/4/23, Samuel Wales wrote: > On 2/1/23, Ihor Radchenko wrote: >> the best we can do is minimizing the breakage when designing the new >> syntax > > as a small nit [followup is not needed as i do not want to distract > from the big boys talking about quantum dst on pluto

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

On 2/1/23, Ihor Radchenko wrote: > the best we can do is minimizing the breakage when designing the new syntax as a small nit [followup is not needed as i do not want to distract from the big boys talking about quantum dst on pluto for timestamps with [axial precession change :[]*, or follow up,

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

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

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

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

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

Jean Louis writes: >> >> [2022-11-12 14:00 @UTC+2] >> >> [2022-11-12 14:00 @UTC-2:30] >> >> >> >> are also fine within the proposed format. >> > >> > The above format is unclear to me. I look at timestamps every day, too >> > many, often change them. >> > >> > I cannot understand what you mean.

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

* Ihor Radchenko [2023-02-01 14:12]: > Let me try to explain better. Just specifying time zone is ambiguous > once per year during daylight transition. For reason to make it unambiguous, people (representatives of countries in international associations) are creating the TZ database, and

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

* Ihor Radchenko [2023-02-02 11:38]: > Jean Louis writes: > > > * Ihor Radchenko [2023-02-01 15:23]: > >> [2022-11-12 14:00 @UTC+2] > >> [2022-11-12 14:00 @UTC-2:30] > >> > >> are also fine within the proposed format. > > > > The above format is unclear to me. I look at timestamps every day,

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

Hi Ihor, >>> with CST being ambiguous (and also not supported by `encode-time’). >> >> I imagine here one could ignore unrecognised but non-conflicting timestamps. > > There is no reliable way to detect if a time zone abbreviation is > ambiguous or not. `encode-time’ will not signal anything and

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

Timothy writes: >> with CST being ambiguous (and also not supported by `encode-time’). > > I imagine here one could ignore unrecognised but non-conflicting timestamps. There is no reliable way to detect if a time zone abbreviation is ambiguous or not. `encode-time' will not signal anything and

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

Hi Ihor, >> It also occurs to me that this proposed behaviour might be easier with a >> single >> `@TZINFO’ form as I mentioned earlier, e.g. >> >> ┌ >> │ [2022-11-12 Sat 12:00]# warn when mismatch >> │ [2022-11-12 Sat 12:00] # use Asia/Singapore over +07 > > Consider the requests

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

Timothy writes: > This functions well, however I see a potential to be confusing at a glance > here. > Consider the visual similarity of 10:30 to 11:00 in local time and 10:30 in > UTC-11, and the combination of both. > > ┌ > │ [2022-11-12 10:30-11:00] > │ [2022-11-12 10:30-1100] > │

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

Max Nikulin writes: > On 01/02/2023 23:45, Ihor Radchenko wrote: >> >> Note how `encode-time' TIME argument has both DST flag and the time zone >> name: >> >> (SECOND MINUTE HOUR DAY MONTH YEAR IGNORED DST ZONE) >> >> DST is necessary exactly in the ambiguous situations like I described,

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

Jean Louis writes: > * Ihor Radchenko [2023-02-01 15:23]: >> [2022-11-12 14:00 @UTC+2] >> [2022-11-12 14:00 @UTC-2:30] >> >> are also fine within the proposed format. > > The above format is unclear to me. I look at timestamps every day, too > many, often change them. > > I cannot understand

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

thanks, Tomas and Ihor, > > [2022-11-12 12:00 @Asia/Singapore] vs. [2022-11-12 12:00 @ Asia/Singapore] > > > > Either way is possible. > > I am in favour of my variant though :) > > Same with me. I read @ as a sigil [1] ... > [1] https://en.wikipedia.org/wiki/Sigil_(computer_programming) i'll

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

Hi Ihor, Thanks for the detailed proposal! The effort you’ve put into soliciting feedback and working out an effective and concise proposal is most commendable . > I propose two forms of time zone information in Org timestamps > > 1. Timestamp with explicit UTC offset > >-MM-DD

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

On 01/02/2023 23:45, Ihor Radchenko wrote: Note how `encode-time' TIME argument has both DST flag and the time zone name: (SECOND MINUTE HOUR DAY MONTH YEAR IGNORED DST ZONE) DST is necessary exactly in the ambiguous situations like I described, when we must know if day saving time is in

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

Jean Louis writes: >> [2023-03-29 02:30+2 @Europe/Berlin] (before transition) >> [2023-03-29 02:30+1 @Europe/Berlin] (after transition) > > Both of the above time stamps do not exist, both are valid. > > If you meant daylight savings time stamps, then you maybe wanted to > say following: > >>

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

Jean Louis writes: >> The problems of daylight savings transition points is fairly well >> understood and I think it is fairly well accepted that there is >> ambiguity arising from the use of daylight savings. > > The only ambiguity is if you miss to understand that "time zone" > definition

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

Jean Louis writes: > Using UTC offset for future time stamps is IMHO possibly much more > problematic for the same reason of possible changes in future. Yes. But it is also an advantage when the purpose is creating timestamp independent of possible changes in future. >> Complex time zones in

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

Jean Louis writes: > Are you going to implement the connection to time zone database? It will be enough to use Emacs time API. `encode-time' accepts time zone as an argument. The time zone in `encode-time' must follow the format for TZ environment variable. Under the hook, `encode-time' uses

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

* Ihor Radchenko [2023-02-01 13:30]: > Tim Cross writes: > > > The real question is, can the additional complexity associated with > > including both a time zone name and an offset be justified in order to > > handle the very small number of time stamps which will fall within the > > daylight

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

* Ihor Radchenko [2023-02-01 15:23]: > [2022-11-12 14:00 @UTC+2] > [2022-11-12 14:00 @UTC-2:30] > > are also fine within the proposed format. The above format is unclear to me. I look at timestamps every day, too many, often change them. I cannot understand what you mean. If there is

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

* Ihor Radchenko [2023-02-01 15:42]: > Indeed. Org is used by a variety of users with different needs. What I > just demonstrated is that specifying the time zone is not always > necessary in timestamps. Specifying time zone in time stamps is not necessary! But using the time zone is necessary

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

* Tim Cross [2023-02-01 12:53]: > > Let me try to explain better. Just specifying time zone is ambiguous > > once per year during daylight transition. > > > > [2023-03-29 02:30 @Europe/Berlin] is special. > > > > According to https://www.timeanddate.com/time/zone/germany/berlin, > > 2023-03-29 is

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

Samuel Wales writes: > amazing amount of work and good choices. i won't object, although > previous comments re syntax proliferation and 3rd party and personal > code re stand, while acknowledging the replies. There is no way around. The feature has been demanded multiple times. It is _needed_

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

On Wed, Feb 01, 2023 at 12:48:12PM +, Ihor Radchenko wrote: > Greg Minshall writes: > > >> 2022-11-12 12:00 @Asia/Singapore # tzdb syntax > > > > aesthetically, allowing a space after the "@" sign might be nice. i > > don't know what that would do to the parsing/BNF/whatever. > >

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

Greg Minshall writes: >> 2022-11-12 12:00 @Asia/Singapore # tzdb syntax > > aesthetically, allowing a space after the "@" sign might be nice. i > don't know what that would do to the parsing/BNF/whatever. [2022-11-12 12:00 @Asia/Singapore] vs. [2022-11-12 12:00 @ Asia/Singapore] Either way is

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

Jean Louis writes: >> Consider that you are running a scientific experiment around daylight >> saving time change: [2022-10-29 2:15-5:15+02]. You don't care that the >> government decided that the wall clock should go like 2:15 -> 2:59 -> >> [CEST -> CET] 2:00 -> 2:15 -> 2:59. Physics does not

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

Christian Moe writes: > From this perspective I'd be happier with the less concise, but super > explicit > > 2022-11-12 14:00 UTC+2 > 2022-11-12 14:00 UTC-2:30 [2022-11-12 14:00 @UTC+2] [2022-11-12 14:00 @UTC-2:30] are also fine within the proposed format. Note, however, that because we

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

Hi, I have only partly been able to follow the discussion, but this seems like a very thoughtful proposal. I'm just not super happy with the ISO format running clock time and offset together, which I thinks makes clock times less readable when you're just quickly glancing through notes. >

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

On 01/02/2023 16:38, Tim Cross wrote: This, combined with the reduced readability of such time stamps and increased possibility of user confusion leads me to question if allowing time stamps with both offset and time zone together in the one time stamp is worthwhile. Readability should not

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

Tim Cross writes: > The real question is, can the additional complexity associated with > including both a time zone name and an offset be justified in order to > handle the very small number of time stamps which will fall within the > daylight savings transition hour for those locations which

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

Ihor Radchenko writes: > Tim Cross writes: > >>> Either I understand you wrong, or you don't know what you are >>> talking about. 2023-03-23 02:30 @Europe/Berlin refers to /two/ >>> points in time, thus it /is/ ambiguous. If you use disambiguating >>> "time zones" (MEZ vs MESZ in this case)

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

Tim Cross writes: >> Either I understand you wrong, or you don't know what you are >> talking about. 2023-03-23 02:30 @Europe/Berlin refers to /two/ >> points in time, thus it /is/ ambiguous. If you use disambiguating >> "time zones" (MEZ vs MESZ in this case) you can resolve that. > > I think

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

* Tim Cross [2023-02-01 11:10]: > I think the confusion relates to context interpretation. If you see > @Europe/Berlin in isolation, then it is ambiguous as it can refer to > two different time zone definitions (standard v daylight savings). Of course, without the time stamp, the time zone alone

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

* to...@tuxteam.de [2023-02-01 10:20]: > Either I understand you wrong, or you don't know what you are > talking about. 2023-03-23 02:30 @Europe/Berlin refers to /two/ > points in time, thus it /is/ ambiguous. If you use disambiguating > "time zones" (MEZ vs MESZ in this case) you can resolve

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

* Thomas S. Dye [2023-02-01 10:05]: > Aloha Jean Louis, > > Jean Louis writes: > > > * Ihor Radchenko [2023-01-31 16:46]: > > > Specifying just @Europe/Berlin is ambiguous around the daylight > > > savings > > > transition. > > > > Sorry, I cannot see practical example why is it ambiguous.

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

writes: > [[PGP Signed Part:Undecided]] > On Tue, Jan 31, 2023 at 11:12:00PM +0300, Jean Louis wrote: >> * Ihor Radchenko [2023-01-31 16:46]: >> > Specifying just @Europe/Berlin is ambiguous around the daylight savings >> > transition. >> >> Sorry, I cannot see practical example why is it

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

On Tue, Jan 31, 2023 at 11:12:00PM +0300, Jean Louis wrote: > * Ihor Radchenko [2023-01-31 16:46]: > > Specifying just @Europe/Berlin is ambiguous around the daylight savings > > transition. > > Sorry, I cannot see practical example why is it ambiguous. Unless > programmer does not take all

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

Aloha Jean Louis, Jean Louis writes: * Ihor Radchenko [2023-01-31 16:46]: Specifying just @Europe/Berlin is ambiguous around the daylight savings transition. Sorry, I cannot see practical example why is it ambiguous. Unless programmer does not take all information in account, it is not

Re: [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 16:46]: > Specifying just @Europe/Berlin is ambiguous around the daylight savings > transition. Sorry, I cannot see practical example why is it ambiguous. Unless programmer does not take all information in account, it is not ambigous. People on this planet agree on

Re: [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 16:46]: > >>For time ranges, we will only allow a single offset and time zone > >>specifier for both start and end times: > >>[2022-11-12 8:00-9:00+08] > >>If different time zones are necessary to specify the start/end times, > >>users can still

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

amazing amount of work and good choices. i won't object, although previous comments re syntax proliferation and 3rd party and personal code re stand, while acknowledging the replies. i cannot take a close look. just a few tiny nits tht shouldn't realy affect much or quite possibly reflect

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

Ihor Radchenko writes: > Greg Minshall writes: > >> just a thought/reminder. there are "semantics" and "encoding". a spec >> like ISO-8601 specifies both. the important thing for org-mode is to >> use an encoding that >> >> 1. is easily parsable/understandable by the mere mortal >> >> 2.

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

Ihor, thanks for all the information. > 2022-11-12 12:00 @Asia/Singapore # tzdb syntax aesthetically, allowing a space after the "@" sign might be nice. i don't know what that would do to the parsing/BNF/whatever. cheers, Greg

Re: [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 14:48]: > I will not follow the standards fully because the available standards > are not designed to be easily understood by humans. Very right, thank you. > 1. https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/ >

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

[ adding Org ML back to CC ] Daryl Manning writes: > OMG it would be amazing if (simply) going <2023-01-31 10:00 @EST> or when > daylight savings time hits <2023-01-31 10:00 @EDT> worked. > > would be *super* happy with that as a user who spends a lot of time dealing > with other time zones. =]

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

Daryl Manning writes: > Dense poll. I had a question about this format which is what I assume I'd > be using if using org-mode with this on a day-to-day basis if given the > choice. > (from 2. Timestamp with time zone specifier) > > 2022-11-12 10:00 @EST+5 # TZ syntax > > Normally, when I'm

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

Jean Louis writes: >>For time ranges, we will only allow a single offset and time zone >>specifier for both start and end times: >>[2022-11-12 8:00-9:00+08] >>If different time zones are necessary to specify the start/end times, >>users can still use full timestamp range

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

Dense poll. I had a question about this format which is what I assume I'd be using if using org-mode with this on a day-to-day basis if given the choice. (from 2. Timestamp with time zone specifier) 2022-11-12 10:00 @EST+5 # TZ syntax Normally, when I'm communicating things like standard and

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

Greg Minshall writes: > just a thought/reminder. there are "semantics" and "encoding". a spec > like ISO-8601 specifies both. the important thing for org-mode is to > use an encoding that > > 1. is easily parsable/understandable by the mere mortal > > 2. allows expression of all the semantics