Sounds about right. B-) -- Bob
On Mon, 03 May 2021 17:27:25 -0400 Steven Winikoff sez:
> >I had an inkling that it might be bad for NMH to try to handle
> >DST calculations on its own;
>
> Tom Scott would agree:
>
>https://www.youtube.com/watch?v=-5wpm-gesOY
>
> This is probably the best
On Mon, 03 May 2021 09:30:46 +0100, Ralph Corderoy said:
> +0845 Australia/Eucla
To quote Casey Schaufler:
EGADS - Concept violates the principle of Least Astonishment.
And here in North America, we tease Newfoundland for being
on the half-hour.
pgp55RpIHwHdW.pgp
Description: PGP
>I had an inkling that it might be bad for NMH to try to handle
>DST calculations on its own;
Tom Scott would agree:
https://www.youtube.com/watch?v=-5wpm-gesOY
This is probably the best explanation I've ever seen of why time
zones and DST calculations induce madness.
- Steven
--
On Mon, 03 May 2021 09:30:46 +0100 Ralph Corderoy sez:
> Hi Bob,
Hi Ralph,
This time you're not giving me happy-useful news. B-D
> > > $ TZ=Australia/Lord_Howe date -d '01 Aug'
> > > 2021-08-01 00:00:00 +1030 Sun
> > > $ TZ=Australia/Lord_Howe date -d '01 Feb'
> > >
Hi Bob,
> > $ TZ=Australia/Lord_Howe date -d '01 Aug'
> > 2021-08-01 00:00:00 +1030 Sun
> > $ TZ=Australia/Lord_Howe date -d '01 Feb'
> > 2021-02-01 00:00:00 +1100 Mon
>
> Wat. -_-##
>
> Why?! I can see some localities deciding that having their time zone
> not be an integer
Wat. -_-##
Why?! I can see some localities deciding that having their time
zone not be an integer number of hours offset can be more
representative or useful for them, but why mess with the DST
offset, too? At this rate, they might as well just create a
server that calculates the sun's
Hi,
Bob wrote:
> I found that (zone) provides you your "standard time" UTC offset (in
> minutes), regardless of (dst)'s result.
nmh's code seems to assume DST means clocks wind forward sixty minutes,
which isn't always true, e.g.
$ TZ=Australia/Lord_Howe date -d '01 Aug'
2021-08-01
bob wrote:
> This thread and Ken's suggestion tempted me to fiddle with this
> stuff, and I found that (zone) provides you your "standard time"
> UTC offset (in minutes), regardless of (dst)'s result. So, this,
> grabbed from my mhl.format file, or something like it might
> suffice for you:
On Tue, 16 Mar 2021 18:38:11 -0400 Ken Hornstein sez:
> >Oh, sure. I guess I was thinking of a more robust solution, that
> >wouldn't require editing that line when my timezone changes twice a
> >year. :-)
>
> Boy, EVERYONE's a critic :-)
>
> You could use the %(dst) function to do the
>Oh, sure. I guess I was thinking of a more robust solution, that
>wouldn't require editing that line when my timezone changes twice a
>year. :-)
Boy, EVERYONE's a critic :-)
You could use the %(dst) function to do the appropriate branching;
you might need to duplicate a fair amount of the
ken wrote:
> >I took a look at trying to suppress the extra output if the timezone is
> >already
> >the same as my local zone, but as far as I can tell, it's not possible.
> >There's
> >no way to get access to the original timezone and the local timezone at the
> >same time, since once
Paul Fox writes:
>
>This works well, and does this for me:
>Date:Mon, 21 Sep 2020 16:03:17 +0200 (Local: Mon 10:03 -0400)
>
>However, it also does this, i.e., it duplicates the date when there's no need.
>Date:Mon, 15 Mar 2021 11:39:04 -0400 (Local: Mon 11:39 -0400)
Personally, I like the
>I took a look at trying to suppress the extra output if the timezone is already
>the same as my local zone, but as far as I can tell, it's not possible.
>There's
>no way to get access to the original timezone and the local timezone at the
>same time, since once you run date2local, the original
There was a quite a thread on this topic back in 12/2014, which was useful to
me this morning when I went looking for a way to get show and scan to show me
dates in the local timezone.
My solution looks like this, thanks to an example that Ken provided back then.
(Line broken up for readability.)
14 matches
Mail list logo
