* Ihor Radchenko [2023-01-18 12:35]:
> > It means there shall be functions which can convert timestamps to the
> > new time zone, with the option to left unchanged those timestamps who
> > already have time zone specified, and with option not to be converted.
>
> I am not sure why you need a
* Ihor Radchenko [2023-01-18 12:29]:
> What should we do when:
>
> 1. It is close to DST transition 2:59 -> 2:00 -> 2:01 -> ... -> 2:59 -> 3:00
>and the users asks to create a timestamp +1h from now
>or, worse, a timestamp +1h from now in a different time zone
I still understand that it
* Ihor Radchenko [2023-01-17 22:51]:
> Some good news is that all the above edge cases would equally affect the
> current Org's timestamp handling code. Yet, we have no bug reports in
> this area. I'd even go further and say that we should not try hard to
> make things 100% accurate: (1) it will
On 17/01/2023 16:45, Tim Cross wrote:
Ihor Radchenko writes:
Tim Cross writes:
It also seems that the solution will need some mechanism (possibly on a
per time stamp basis) for the user to specify what should happen when
either the time zone has a daylight savings transition, when the
Tim Cross writes:
>> Does it sound good enough?
>
> No, I'm afraid not. How does org distinguish between meeting 1 and
> meeting 2? IN meeting one, when the timezone transitions in/out of
> daylight savings, nothing needs to change, but in meeting 2, when this
> occurs, the meeting needs to be
Ihor Radchenko writes:
> Tim Cross writes:
>
>>> Could you please elaborate here?
>>
>> I have some meetings scheduled in my org files which show up in the
>> agenda.
>>
>> Meeting 1 is a reoccurring meeting which happens every 2 weeks. All of
>> the people in that meting are in the same
Max Nikulin writes:
> ... I am unsure concerning Windows, it may have an option of quite
> similar variant. That is why I am not sure to which degree Org should be
> liberal in respect to various time zones.
May we just support whatever TZ supports (POSIX)?
I was also thinking about ISO
Jean Louis writes:
>> >> I am not sure what is the problem.
>> >> The timestamps that should stay in local time will be automatically
>> >> updated as your system TZ is updated.
>> >
>> > Then Org shall know what was local time! Without being specified in
>> > the time stamp, it has to be
Jean Louis writes:
> When there is global variable for Org file about time zone, then:
>
> - every timestamp with time zone, shall be left intact or
> re-calculated to diffrent local time zone. Imagine person giving Org
> file from Russia to somebody in Florida, or travelling there. That
> user
Jean Louis writes:
> ...
> Should be part of C library to observe those things.
Sure. My previous proposals are all relying on `encode-time' which uses
time.h from system libraries and utilizing TZDB that is taking care
about all this insanity.
We, however, might need to be careful about
Tim Cross writes:
>> Could you please elaborate here?
>
> I have some meetings scheduled in my org files which show up in the
> agenda.
>
> Meeting 1 is a reoccurring meeting which happens every 2 weeks. All of
> the people in that meting are in the same timezone as I'm in. When we
> transition
Max Nikulin writes:
> https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time
>Falsehoods programmers believe about time
Some potentially relevant items:
- Each calendar date is followed by the next in sequence, without
skipping.
- The standard library
On 17/01/2023 01:37, Ihor Radchenko wrote:
Some formats may be confusing for users, e.g. TZ=GMT+5 actually means
-0500 offset.
Let's just recommend +- and @location in the manual. And mention
briefly that TZ format is supported in addition.
We might also provide an optional linter for GMT,
On 17/01/2023 02:07, Ihor Radchenko wrote:
https://www.youtube.com/watch?v=-5wpm-gesOY gives various examples.
More links:
- https://stackoverflow.com/tags/timezone/info
-
https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time
Falsehoods programmers believe
* Ihor Radchenko [2023-01-16 22:08]:
> 1. Time (-MM-DD HH:MM) not continuous and may change arbitrarily at
>certain times a year or in future or in the past:
I am sure that system library must be responsible to know those
changes. It is not for Org.
So the calculation which transforms
* Ihor Radchenko [2023-01-16 14:21]:
> In another message, I also mentioned an idea of specifying time zone
> globally or per file. Other suggestion was per-heading specification. In
> addition to time zone being specified directly inside the timestamp.
Of course that is solution. iCalendar
* Ihor Radchenko [2023-01-16 14:25]:
> Jean Louis writes:
>
> >> I am not sure what is the problem.
> >> The timestamps that should stay in local time will be automatically
> >> updated as your system TZ is updated.
> >
> > Then Org shall know what was local time! Without being specified in
> >
Ihor Radchenko writes:
> Tim Cross writes:
>
>> It also seems that the solution will need some mechanism (possibly on a
>> per time stamp basis) for the user to specify what should happen when
>> either the time zone has a daylight savings transition, when the
>> timezone rules change or when
Tim Cross writes:
> It also seems that the solution will need some mechanism (possibly on a
> per time stamp basis) for the user to specify what should happen when
> either the time zone has a daylight savings transition, when the
> timezone rules change or when the user's 'default' time zone
Tim Cross writes:
> Daryl Manning writes:
>
>> I think timezone you're in should be declared globally, surely? And then
>> defined in the timestamp?
>>
>
> Do you mean globally as in at the OS level or globally in org mode. If
> the latter, I disagree. The OS has this information and there is
Robert Horn writes:
> Those who wanted astronomical or other relationships would usually
> specify UTC or TAI. They might use a fixed offset for UTC. People who
> are into the demands of TAI (e.g., orbital mechanics) generally don't
> want to deal with the offsets or other issues that come up
Daryl Manning writes:
> 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
Robert Horn writes:
>> 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
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
Tom Gillespie writes:
>> 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.
>
> This is related to why I suggested splitting timezones
> 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.
This is related to why I suggested splitting timezones and offsets into
two separate
Ihor Radchenko writes:
> Robert Horn writes:
>
>>> 1. Time (-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
> > As for years BC, <-0001-...> will be a breaking change. But I do not
> > think that we need to really worry about this. Not unless we actually
> > get feature request. What is the practical application?
Using org as a format for writing about history and being able to
reference dates in the
Ihor Radchenko writes:
> Tom Gillespie writes:
>
>
>> I will note that this doesn't address the issue of syntax for
>> historical and future dates. For historical dates those almost always
>> require significant additional metadata to compensate for things like
>> the julian/gregorian calendar
Daryl Manning writes:
> I think timezone you're in should be declared globally, surely? And then
> defined in the timestamp?
>
Do you mean globally as in at the OS level or globally in org mode. If
the latter, I disagree. The OS has this information and there is no need
for org to repeat it
Robert Horn writes:
>> 1. Time (-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
>>
Ihor Radchenko writes:
> https://www.youtube.com/watch?v=-5wpm-gesOY gives various examples.
> To summarize:
>
> 1. Time (-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
Daryl Manning writes:
> I'd just be excited to have us run through the basic use cases and then see
> some more "tricky" ones. I imagine there are things we'd just have to
> say... too tricky for (eg. flight takes off in one TZ and range allows it
> to land in timezone... stuff like that might
Max Nikulin writes:
>> Are you referring to one hour in year when the clock is moved one hour
>> forward?
>>
>> <2023-10-29 Sun 3:00@+DST/Europe/Berlin> -> (+1 minute)
>> <2023-10-29 Sun 2:01@-DST/Europe/Berlin>
>>
>> I, however, do not feel like we need this +/-DST special notation.
>>
Tom Gillespie writes:
>> I strongly disagree. I'd prefer to allow only internationally recognized
>> time zone format. Let's not make life harder for Org file parsers.
>
> So offsets and tz database names but no time zone abbreviations?
>
> That seems reasonable since there isn't a sane way to
> I strongly disagree. I'd prefer to allow only internationally recognized
> time zone format. Let's not make life harder for Org file parsers.
So offsets and tz database names but no time zone abbreviations?
That seems reasonable since there isn't a sane way to handle the
timezone with dst vs
On 15/01/2023 20:41, Ihor Radchenko wrote:
Max Nikulin writes:
On 14/01/2023 18:42, Ihor Radchenko wrote:
<2023-01-14 Sat 18:22@Asia/Singapore> (SGD and similar abbreviations are often
ambiguous)
Such format is ambiguous for timezones with DST around backward time
jump. Before/after time
I agree... TZ is optionally defined in a timestamp otherwise understood to
be "local".
I'd just be excited to have us run through the basic use cases and then see
some more "tricky" ones. I imagine there are things we'd just have to
say... too tricky for (eg. flight takes off in one TZ and range
Tom Gillespie writes:
>> So I guess the timestamp format and the code which manages them will
>> need the ability to use the full TZ name and not just the abbreviated
>> form (and I guess an option to allow the user to select). In fact, we
>> probably need a way to select between
Tim Cross writes:
> If the timestamp only contains the abbreviated name e.g. AEST, then
> there is no automatic way to disambiguate - best we could
> do is issue a warning. The abbreviated TZ name, unlike the full TZ name,
> is really just a shorthand for the time offset from UTC at a specific
>
Jean Louis writes:
> One could think for Org to simply become able to designate time zone
> somewhere, be it generally for Org file or/and specific heading, or/and
> specific timestamp.
>
> Then implement function to transform time to UTC, and then use
> libraries or Emacs to transform UTC to
Jean Louis writes:
> In the context of Org files, that would mean that there must exist
> function which would convert time zone timestamps into local time zone
> for proper representation.
>
> Only with such functions problems are gone.
>
> Without such function to convert time zones in
Jean Louis writes:
> * Ihor Radchenko [2023-01-14 20:08]:
>> > When you have appointments with people in totally diverse time zones,
>> > perhaps dates tend to be more fixed wrt UTC.
>>
>> AFAIK, people don't usually bother.
>
> Can't agree to that, we who do bother will simply find different
Tom Gillespie writes:
>> Note that REST imply that almost arbitrary suffix can be in TIME without
>> braking the existing Org timestamp parsing code.
>
> I'm not sure how I feel about the REST in the grammar, I think it is a
> reasonable approach but need to double check. I'm worried that there
Daryl Manning writes:
> I think timezone you're in should be declared globally, surely? And then
> defined in the timestamp?
It is always defined globally on OS level. In POSIX-complaint OSes, it is
TZ. Emacs obeys POSIX and time zone settings in other OSes. We don't
need anything special for
I think timezone you're in should be declared globally, surely? And then
defined in the timestamp?
The use cases for per file or even per-heading tz specifying seems very low
imho (and introducing a lot more complexity.).
Daryl.
On Mon, Jan 16, 2023 at 6:20 PM Ihor Radchenko wrote:
> Jean
Jean Louis writes:
>> I am not sure what is the problem.
>> The timestamps that should stay in local time will be automatically
>> updated as your system TZ is updated.
>
> Then Org shall know what was local time! Without being specified in
> the time stamp, it has to be specified somewhere, as
Jean Louis writes:
> * Ihor Radchenko [2023-01-14 16:23]:
>> But why do we need any time zone data? All we need to converting from
>> and to internal Emacs' time representation supplying the correct time
>> zone to it.
>
> When Org file is very personal and location centric, then there is no
>
> So I guess the timestamp format and the code which manages them will
> need the ability to use the full TZ name and not just the abbreviated
> form (and I guess an option to allow the user to select). In fact, we
> probably need a way to select between abbreviated/full dynamically as
> well as
> In anticipation to add time zones in future, I have added the following
> to the Org timestamp spec (see
> https://orgmode.org/worg/org-syntax.html#Timestamps):
>
> DATE TIME REPEATER-OR-DELAY
>
> TIME (optional)
> An instance of the pattern H:MMREST where H represents a one to two digit
>
On 16/01/2023 02:14, Jean Louis wrote:
As PostgreSQL type TIMESTAMP WITH TIME ZONE is stored with underlying
UTC time, so should be Org times also be calculated with underlying
UTC times.
Org currently can properly handle the following case:
Let's assume that current date is 2022-07-01. A
Ihor Radchenko writes:
> Tim Cross writes:
>
>> Unfortunately, the common abbreviated forms like EST, AEST etc are
>> inconsistent here. Some places will have a standard and a daylight
>> savings type i.e. AEST and AEDT, while others will have just AEST. TO
>> make it worse, two locations with
* Ihor Radchenko [2023-01-14 16:23]:
> Tim Cross writes:
>
> > Consider for example an agenda file where the TODO items have been added
> > while I am here in Australia (currently +11:00 w/ DST). Tomorrow I fly
> > to Europe where I will be working for the next 6 weeks. I need all my
> > TODOs
* Tim Cross [2023-01-15 00:40]:
> The internal representation of timestamps used by Postgres is ALWAYS
> UTC, regardless of whether the field was defined as timestamp or
> timestamp with timezone.
Right.
> The only real difference is that if the field is defined as just
> timestamp, postgres
* Max Nikulin [2023-01-15 08:05]:
> I totally agree with the recommendation to use timestamptz for data related
> to something in history: billing, bank transactions, etc.
>
> However it is call to trouble for planned events and schedules. Not
> frequent, so almost untested use cases.
>
> If I
* Ihor Radchenko [2023-01-14 20:08]:
> > When you have appointments with people in totally diverse time zones,
> > perhaps dates tend to be more fixed wrt UTC.
>
> AFAIK, people don't usually bother.
Can't agree to that, we who do bother will simply find different
solutions but Org, like I have
* Tim Cross [2023-01-15 01:13]:
> I think I basically agree with the last statement. However, perhaps we
> need to step back and ask ourselves what it is that people do want which
> drives this feature request. I doubt it is simply the ability to add TZ
> information to timestamps. I suspect the
* to...@tuxteam.de [2023-01-14 20:16]:
> What I can imagine being useful (besides allowing timestamps to carry
> that extra info) is the possibility to set defaults, perhaps at the
> file (even, who knows, at the heading) level. A special attribute
> seems pretty adequate, if I'm not missing some
Aloha all,
IIUC, timestamps in Org might be used to track two things: events
and occurrences.
An event refers to a particular region of space/time, in Org's
case the space/time occupied by the user, regardless of which time
zone the user occupies. An event might be "Brush teeth before
* Tim Cross [2023-01-15 10:58]:
> WRT future timestamps, we would probably have to take the same
> approach as postgres i.e. the timezone rules in force at the time
> the timestamp is created are assumed to be 'forever'. While this is
> not true, it is really the only solution you can adopt and
* Tim Cross [2023-01-14 23:25]:
> Yes, this is a problem. We really want a symbolic TZ
> specification and we would need 'smarts' i the timestamp generation code
> that is able to handle potential offset changes due to daylight savings
> transition etc. Even then, the transition time can change
* Ihor Radchenko [2023-01-14 16:23]:
> But why do we need any time zone data? All we need to converting from
> and to internal Emacs' time representation supplying the correct time
> zone to it.
When Org file is very personal and location centric, then there is no
need for it.
When Org file has
* Max Nikulin [2023-01-14 19:59]:
> On 14/01/2023 20:08, Jean Louis wrote:
> > * Max Nikulin [2023-01-14 10:14]:
> > > Let's assume <2023-01-15 Sun 09:00 +1>
> > >
> > > It may be suitable for timestamps in the past, but future is more tricky.
> > > There is no problem if you are going to watch
Tim Cross writes:
> Unfortunately, the common abbreviated forms like EST, AEST etc are
> inconsistent here. Some places will have a standard and a daylight
> savings type i.e. AEST and AEDT, while others will have just AEST. TO
> make it worse, two locations with the same time zone offset my use
Max Nikulin writes:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54764#30
> Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list
> Thu, 14 Apr 2022 15:46:58 -0700
>> If you want to keep the TZDB identifier for advice about how to
>> interpret dates relative to a timestamp,
Tim Cross writes:
>> In any case, selection of time zone for user timestamps is not something
>> we need to worry about in Org code. Users are to decide. Org might
>> assist, but I do not see anything meaningful we can do to help with DST.
>
> I think I basically agree with the last statement.
Max Nikulin writes:
> On 14/01/2023 18:42, Ihor Radchenko wrote:
>>
>> <2023-01-14 Sat 18:22@Asia/Singapore> (SGD and similar abbreviations are
>> often ambiguous)
>
> Such format is ambiguous for timezones with DST around backward time
> jump. Before/after time transition should be
Max Nikulin writes:
> On 15/01/2023 03:30, Tim Cross wrote:
>> The UTC time stays the same, but the
>> meeting time for me changes twice per year (moving forward/backward an
>> hour).
>
> Meeting time remains the same expressed as local time (15:00), but alternates
> between
> 04:00 and 05:00
On Sun, Jan 15, 2023 at 06:43:19AM +1100, Tim Cross wrote:
> Max Nikulin writes:
>
> > On 14/01/2023 20:08, Jean Louis wrote:
> >> * Max Nikulin [2023-01-14 10:14]:
> >>> Let's assume <2023-01-15 Sun 09:00 +1>
> >>>
> >>> It may be suitable for timestamps in the past, but future is more tricky.
On 14/01/2023 18:42, Ihor Radchenko wrote:
<2023-01-14 Sat 18:22@Asia/Singapore> (SGD and similar abbreviations are often
ambiguous)
Such format is ambiguous for timezones with DST around backward time
jump. Before/after time transition should be specified in addition, e.g.
by combining
On 14/01/2023 22:05, Ihor Radchenko wrote:
writes:
Now there's still enough work for the applications to do: presentation,
parsing, disambiguation, if necessary asking the user for help. Someone
mentioned PostgreSQL -- this is a nice example of what can be done beyond
the (comparatively!)
On 14/01/2023 22:05, Ihor Radchenko wrote:
In addition, we may provide some mechanism to set the time zone for:
1. Individual files
2. For all files, including possible time zone transitions over time.
What I mean by (2) is when the user travels from, say, Australia to USA,
it could be possible
On 15/01/2023 03:30, Tim Cross wrote:
The UTC time stays the same, but the
meeting time for me changes twice per year (moving forward/backward an
hour).
Meeting time remains the same expressed as local time (15:00), but
alternates between 04:00 and 05:00 UTC. So repeating schedule can not be
Ihor Radchenko writes:
> to...@tuxteam.de writes:
>
>>> ... Having an
>>> ability to specify time zones manually will already cater needs for a
>>> number of users.
>>
>> Definitely. But the time stamp (with time zone) in itself doesn't
>> carry enough context to actually decide that. It's even
to...@tuxteam.de writes:
> [[PGP Signed Part:Undecided]]
> On Sat, Jan 14, 2023 at 03:05:22PM +, Ihor Radchenko wrote:
>> writes:
>>
>> > Now there's still enough work for the applications to do: presentation,
>> > parsing, disambiguation, if necessary asking the user for help. Someone
>> >
Max Nikulin writes:
> On 14/01/2023 20:50, Tim Cross wrote:
>> I"m sorry, but I don't follow. The UTC time is the only time whihc is
>> not affected by daylight savings transitions, so is the only stable
>> metric. All the others are relative to that time but can change based on
>> things like
Max Nikulin writes:
> On 14/01/2023 20:08, Jean Louis wrote:
>> * Max Nikulin [2023-01-14 10:14]:
>>> Let's assume <2023-01-15 Sun 09:00 +1>
>>>
>>> It may be suitable for timestamps in the past, but future is more tricky.
>>> There is no problem if you are going to watch Lunar eclipse. However
On Sat, Jan 14, 2023 at 05:06:31PM +, Ihor Radchenko wrote:
> to...@tuxteam.de writes:
>
> >> ... Having an
> >> ability to specify time zones manually will already cater needs for a
> >> number of users.
> >
> > Definitely. But the time stamp (with time zone) in itself doesn't
> > carry
to...@tuxteam.de writes:
>> ... Having an
>> ability to specify time zones manually will already cater needs for a
>> number of users.
>
> Definitely. But the time stamp (with time zone) in itself doesn't
> carry enough context to actually decide that. It's even not that
> easy to wrap one's head
On 14/01/2023 20:08, Jean Louis wrote:
* Max Nikulin [2023-01-14 10:14]:
Let's assume <2023-01-15 Sun 09:00 +1>
It may be suitable for timestamps in the past, but future is more tricky.
There is no problem if you are going to watch Lunar eclipse. However if your
plan is to attend a local event
On 14/01/2023 20:50, Tim Cross wrote:
I"m sorry, but I don't follow. The UTC time is the only time whihc is
not affected by daylight savings transitions, so is the only stable
metric. All the others are relative to that time but can change based on
things like changes in DST transition
On Sat, Jan 14, 2023 at 03:05:22PM +, Ihor Radchenko wrote:
> writes:
>
> > Now there's still enough work for the applications to do: presentation,
> > parsing, disambiguation, if necessary asking the user for help. Someone
> > mentioned PostgreSQL -- this is a nice example of what can be
writes:
> Now there's still enough work for the applications to do: presentation,
> parsing, disambiguation, if necessary asking the user for help. Someone
> mentioned PostgreSQL -- this is a nice example of what can be done beyond
> the (comparatively!) boring details of time zone management
On Sat, Jan 14, 2023 at 02:38:05PM +, Ihor Radchenko wrote:
[...]
> > Or to put it in another way - currently, it is well understood where org
> > timestamps fall down. However, once you add TZ and provide the
> > expectation TZ data will be respected correctly, all bets are off.
>
> I
Tim Cross writes:
>> This is not the problem we need to worry about. We can use whatever
>> Emacs provides and rely on future improvements in Emacs where things are
>> deficient. We should not aim for 100% accurate time zone support. Just
>> good enough. It's not Org's job to implement the gory
Ihor Radchenko writes:
> Tim Cross writes:
>
>> Daryl mentioned elsewhere in this thread that how hard this feature
>> would be depends largely on the available libraries for elisp with
>> respect to working with date/time values. Sadly, the available elisp
>> libraries are inadequate in this
Max Nikulin writes:
> On 14/01/2023 16:32, Tim Cross wrote:
>> If org was to add TZ capabilities to timestamps, the underlying format
>> would have to be UTC.
> ...
>> can change based on various criteria, including political whims
>> (e.g. Australia eastern DST transition date was changed in
Tim Cross writes:
> Consider for example an agenda file where the TODO items have been added
> while I am here in Australia (currently +11:00 w/ DST). Tomorrow I fly
> to Europe where I will be working for the next 6 weeks. I need all my
> TODOs with active timestamps to be updated to Berlin's
Ihor Radchenko writes:
> Tim Cross writes:
>
>> I agree this would be a great feature to add. However, after having
>> looked at it in some detail, I realise that not only is it not a trivial
>> task, it is actually a very large and complex task and will require
>> extensive work which will
* Max Nikulin [2023-01-14 10:14]:
> Let's assume <2023-01-15 Sun 09:00 +1>
>
> It may be suitable for timestamps in the past, but future is more tricky.
> There is no problem if you are going to watch Lunar eclipse. However if your
> plan is to attend a local event there is a chance that you
* Daryl Manning [2023-01-14 09:30]:
> To Jean Louis' point: using timestamps without timezones is a don't in much
> of computing these days and perhaps hearkens back to the simpler age emacs
> and org originated in. =] (kidding!).
I see it that way, yes. Isn't it so.
--
Jean
Take action in
Russell Adams writes:
>> Calc's time zone calculations are hard coded. We should rather rely on
>> OS library primitives. They have better chances to get updated as
>> politics changes in some countries.
>
> I had no idea.
>
> Wouldn't Emacs be updated eventually if timezones change? Doesn't it
On Sat, Jan 14, 2023 at 12:19:17PM +, Ihor Radchenko wrote:
> Russell Adams writes:
>
> > Doesn't Emacs Calc have timezone conversion functions natively?
>
> Calc's time zone calculations are hard coded. We should rather rely on
> OS library primitives. They have better chances to get updated
Russell Adams writes:
> Doesn't Emacs Calc have timezone conversion functions natively?
Calc's time zone calculations are hard coded. We should rather rely on
OS library primitives. They have better chances to get updated as
politics changes in some countries.
--
Ihor Radchenko // yantar92,
On Sat, Jan 14, 2023 at 11:35:00AM +, Ihor Radchenko wrote:
> Russell Adams writes:
>
> > Can't Org also ready diary formatted timestamps?
>
> We support diary sexps.
>
> > Do those include timezones?
>
> No, AFAIK. sexps may (they are just Elisp functions, anyway).
>
> > I know they include
On 14/01/2023 16:32, Tim Cross wrote:
If org was to add TZ capabilities to timestamps, the underlying format
would have to be UTC.
...
can change based on various criteria, including political whims
(e.g. Australia eastern DST transition date was changed in 2000 because
Sydney hosted the
Daryl Manning writes:
> Can you give an example like below? What does it look like?
> And say, with a recurring data like once a week and a warning of 5d early?
>
> I believe /most/ people would be looking for something grokable like:
> <2023-01-14 Sat 18:22 SGT> or say
> <2023-01-14 Sat 18:22
Russell Adams writes:
> Can't Org also ready diary formatted timestamps?
We support diary sexps.
> Do those include timezones?
No, AFAIK. sexps may (they are just Elisp functions, anyway).
> I know they include better repeat information. Maybe we can
> build on that?
Is it really better?
Tim Cross writes:
> Daryl mentioned elsewhere in this thread that how hard this feature
> would be depends largely on the available libraries for elisp with
> respect to working with date/time values. Sadly, the available elisp
> libraries are inadequate in this area. While many of the functions
Hey Ihor,
Sorry, I had a little trouble understanding the way you have the syntax
written in that timestamps doc.
Can you give an example like below? What does it look like?
And say, with a recurring data like once a week and a warning of 5d early?
I believe /most/ people would be looking for
101 - 200 of 210 matches
Mail list logo
