On Fri, Apr 23, 2021 at 09:45:14AM +0800, Shironeko wrote:
> Hi all,
>
> I originally thought having the timezone in the header of the file would make
> things simpler, since it meant all the timestamp would be in the same
> timezone,
> rather than potentially different ones. But it seems that
Hi all,
I originally thought having the timezone in the header of the file would make
things simpler, since it meant all the timestamp would be in the same timezone,
rather than potentially different ones. But it seems that that might not be
inline with how others use their org files.
org
The notes below are quite general and unrelated to particular message.
On 04/04/2021 07:51, Tom Gillespie wrote:
followed by a space and then the repeat or delay for example
[+1-01-01 10:11:00,992315771-04:00 Sat] or
[-480-08-20 05:00+01:00]
or more temporally local
[2021-03-03 17:43-07:00
Time zones are tricky, but there are some requirements that make it
possible to rule out many apparent solutions because they violate some
critical invariant. For example. Timezone cannot be scoped to the
file. This is because many users (myself included) have a single org
file that is used in and
Greg Minshall writes:
> Russell,
>
>> I would not suggest using UTC. I believe one of the reasons timestamps
>> didn't include TZ information was to keep them short and human
>> legible. Solutions with overlays to change a timestamp reduce the
>> usefulness of the plain text reading of Org
the suggestion to change all your tses to utc was not a general
suggestion for all org users or a change to org. for op only.
but the point about grep and such then breaking is a good one. it is
possibly not a useful workaround for the op.
On 4/3/21, Greg Minshall wrote:
> Russell,
>
>> I
Russell,
> I would not suggest using UTC. I believe one of the reasons timestamps
> didn't include TZ information was to keep them short and human
> legible. Solutions with overlays to change a timestamp reduce the
> usefulness of the plain text reading of Org (ie: less, grep,
> etc). Storing
On Sat, Apr 03, 2021 at 02:23:34PM +0300, Greg Minshall wrote:
> > #+TIMEZONE: America/Toronto
> >
> > at the start of their org file, and they moved to Shanghai, all the
> > timestamp in
> > the org file is converted using something equivalent to
I think what you're saying here is that
The reason there is such a database is precisely that it is meant to change,
leap seconds are irregular and other laws change all the time (perhaps DST gets
removed (please)).
Setting all timestamps to UTC is the ideal solution for sure (perhaps as an
option) and other things that deal with org
The only ambiguous timestamp is the hour when exiting DST (dialing back), and
that time is usually set to when there is not much going on (like midnight). all
other time do not need to specify whether its DST or not, which fits in with the
current timestamp format.
signature.asc
Description:
On Sat, Apr 03, 2021 at 05:26:43PM +0800, Shironeko wrote:
> tz database and tools using it like the date(1) command can convert between
> local times taking into account all the difference like daylight savings time.
> An example below, Toronto observes daylight savings whereas Shanghai does not:
hi, Shiro,
> With this, say the user have
>
> #+TIMEZONE: America/Toronto
>
> at the start of their org file, and they moved to Shanghai, all the timestamp
> in
> the org file is converted using something equivalent to
>
> $ TZ=Asia/Shanghai date --date='TZ="America/Toronto" '"$TIMESTAMP"
>
tz database and tools using it like the date(1) command can convert between
local times taking into account all the difference like daylight savings time.
An example below, Toronto observes daylight savings whereas Shanghai does not:
$ TZ=Asia/Shanghai date --date='TZ="America/Toronto" 2021-11-07
On Sat, Apr 03, 2021 at 08:03:18AM +, shironeko wrote:
> see https://en.m.wikipedia.org/wiki/Tz_database
That's where I looked at (OK, without the "m" in the URL ;-)
But I still don't understand what you are up to, so it might
be we are talking past each other.
What's described there is a
see https://en.m.wikipedia.org/wiki/Tz_database
On Sat, Apr 03, 2021 at 08:36:06AM +0800, Shironeko wrote:
> On Fri, 2021-04-02 at 13:34 +0200, to...@tuxteam.de wrote:
> > On Thu, Apr 01, 2021 at 07:40:47AM +, shironeko wrote:
> >
> > Hm. Just a mumbling from the peanut gallery: isn't the timezone a property
> > of the timestamp itself?
>
what i proposed is this. which uses text properties. it might not
suit your needs, but might be a workaround. at least it is a
brainstorm. suitable for wrapping fish.
1] convert all your tses to utc [exercise for the reader]
2] make org's idea of time be utc [there /might/ be code]
3] make
On Sat, 2021-04-03 at 10:37 +1100, Tim Cross wrote:
>
> 1. Timzone alone is not sufficient. Offsets from UTC change due to
> daylight savings times etc.
>
> 2. You can easily have timestamps from different timezones in the same
> org file
>
> 3. Storing timestamps in local time is problematic
On Fri, 2021-04-02 at 13:34 +0200, to...@tuxteam.de wrote:
> On Thu, Apr 01, 2021 at 07:40:47AM +, shironeko wrote:
>
> Hm. Just a mumbling from the peanut gallery: isn't the timezone a property
> of the timestamp itself?
>
> Specifying the timezone for the whole file is progress, but
org has capability of overlaying [or similar] tses with user-defined
something or other. for locale type purposes.
perhaps, in principle, all tses for users who need tz could be in utc
or similar, and such overlays could be used to localize on the fly?
On 4/2/21, Tim Cross wrote:
>
> shironeko
shironeko writes:
> Hi everyone,
>
> I, like many others on this list, have to move between timezones quite
> frequently. As I gathered from the archive, it seems the main complexity in
> supporting timezones is the difficulty revolving the change of timestamp
> format.
> So I have an idea,
On Thu, Apr 01, 2021 at 07:40:47AM +, shironeko wrote:
> Hi everyone,
>
> I, like many others on this list, have to move between timezones quite
> frequently. As I gathered from the archive, it seems the main complexity in
> supporting timezones is the difficulty revolving the change of
Hi everyone,
I, like many others on this list, have to move between timezones quite
frequently. As I gathered from the archive, it seems the main complexity in
supporting timezones is the difficulty revolving the change of timestamp format.
So I have an idea, suppose we add a new keyword,
Hi everyone,
I, like many others on this list, have to move between timezones quite
frequently. As I gathered from the archive, it seems the main complexity in
supporting timezones is the difficulty revolving the change of timestamp format.
So I have an idea, suppose we add a new keyword,
24 matches
Mail list logo
