Re: ntpsec as server questions
Sent from my iPad
> On Dec 6, 2023, at 1:28 PM, Greg Wooledge <greg@wooledge.org> wrote:
>
> On Wed, Dec 06, 2023 at 01:02:45PM -0500, Pocket wrote:
>> TZ=POSIX;date
>> Wed Dec 6 18:00:38 POSIX 2023
>
> "POSIX" is not a valid timezone name in Debian 12. Therefore you're
> just seeing UTC here. Giving an invalid TZ always gives you UTC, but
> with whatever crazy-ass name you used echoed back at you, to give you
> the illusion that your name was valid. It's a *huge* pitfall. I've been
> bit by this myself.
>
>> TZ=America/New_York;date
>> Wed Dec 6 13:00:21 EST 2023
>> TZ=EST5DST;date
>> Wed Dec 6 13:01:10 EST 2023
>> What is the problem?
>
> Gods DAMN it. I didn't want to have to dig through these stupid zone
> dumps, but you're FORCING my hand.
>
> unicorn:~$ zdump -v -c 1918,1950 EST5EDT
> EST5EDT -9223372036854775808 = NULL
> EST5EDT -9223372036854689408 = NULL
> EST5EDT Sun Mar 31 06:59:59 1918 UT = Sun Mar 31 01:59:59 1918 EST isdst=0 gmtoff=-18000
> EST5EDT Sun Mar 31 07:00:00 1918 UT = Sun Mar 31 03:00:00 1918 EDT isdst=1 gmtoff=-14400
> EST5EDT Sun Oct 27 05:59:59 1918 UT = Sun Oct 27 01:59:59 1918 EDT isdst=1 gmtoff=-14400
> EST5EDT Sun Oct 27 06:00:00 1918 UT = Sun Oct 27 01:00:00 1918 EST isdst=0 gmtoff=-18000
> EST5EDT Sun Mar 30 06:59:59 1919 UT = Sun Mar 30 01:59:59 1919 EST isdst=0 gmtoff=-18000
> EST5EDT Sun Mar 30 07:00:00 1919 UT = Sun Mar 30 03:00:00 1919 EDT isdst=1 gmtoff=-14400
> EST5EDT Sun Oct 26 05:59:59 1919 UT = Sun Oct 26 01:59:59 1919 EDT isdst=1 gmtoff=-14400
> EST5EDT Sun Oct 26 06:00:00 1919 UT = Sun Oct 26 01:00:00 1919 EST isdst=0 gmtoff=-18000
> EST5EDT Mon Feb 9 06:59:59 1942 UT = Mon Feb 9 01:59:59 1942 EST isdst=0 gmtoff=-18000
> EST5EDT Mon Feb 9 07:00:00 1942 UT = Mon Feb 9 03:00:00 1942 EWT isdst=1 gmtoff=-14400
> EST5EDT Tue Aug 14 22:59:59 1945 UT = Tue Aug 14 18:59:59 1945 EWT isdst=1 gmtoff=-14400
> EST5EDT Tue Aug 14 23:00:00 1945 UT = Tue Aug 14 19:00:00 1945 EPT isdst=1 gmtoff=-14400
> EST5EDT Sun Sep 30 05:59:59 1945 UT = Sun Sep 30 01:59:59 1945 EPT isdst=1 gmtoff=-14400
> EST5EDT Sun Sep 30 06:00:00 1945 UT = Sun Sep 30 01:00:00 1945 EST isdst=0 gmtoff=-18000
> EST5EDT 9223372036854689407 = NULL
> EST5EDT 9223372036854775807 = NULL
>
> OK? There's dump number one. Now let's compare to dump number two:
>
> unicorn:~$ zdump -v -c 1918,1950 America/New_York
> America/New_York -9223372036854775808 = NULL
> America/New_York -9223372036854689408 = NULL
> America/New_York Sun Mar 31 06:59:59 1918 UT = Sun Mar 31 01:59:59 1918 EST isdst=0 gmtoff=-18000
> America/New_York Sun Mar 31 07:00:00 1918 UT = Sun Mar 31 03:00:00 1918 EDT isdst=1 gmtoff=-14400
> America/New_York Sun Oct 27 05:59:59 1918 UT = Sun Oct 27 01:59:59 1918 EDT isdst=1 gmtoff=-14400
> America/New_York Sun Oct 27 06:00:00 1918 UT = Sun Oct 27 01:00:00 1918 EST isdst=0 gmtoff=-18000
> America/New_York Sun Mar 30 06:59:59 1919 UT = Sun Mar 30 01:59:59 1919 EST isdst=0 gmtoff=-18000
> America/New_York Sun Mar 30 07:00:00 1919 UT = Sun Mar 30 03:00:00 1919 EDT isdst=1 gmtoff=-14400
> America/New_York Sun Oct 26 05:59:59 1919 UT = Sun Oct 26 01:59:59 1919 EDT isdst=1 gmtoff=-14400
> America/New_York Sun Oct 26 06:00:00 1919 UT = Sun Oct 26 01:00:00 1919 EST isdst=0 gmtoff=-18000
> America/New_York Sun Mar 28 06:59:59 1920 UT = Sun Mar 28 01:59:59 1920 EST isdst=0 gmtoff=-18000
> America/New_York Sun Mar 28 07:00:00 1920 UT = Sun Mar 28 03:00:00 1920 EDT isdst=1 gmtoff=-14400
> America/New_York Sun Oct 31 05:59:59 1920 UT = Sun Oct 31 01:59:59 1920 EDT isdst=1 gmtoff=-14400
> America/New_York Sun Oct 31 06:00:00 1920 UT = Sun Oct 31 01:00:00 1920 EST isdst=0 gmtoff=-18000
> [...]
>
> I'm truncating this one because it's much longer. Apparently this one
> shows every year, even if there are no DST rule changes that year. What
> does this mean? Hell if I know. Let's pick a date that's in one of
> these dumps but not the other, shall we?
>
> unicorn:~$ TZ=America/New_York date -d '1920-03-28 +4 hours'
> Sun Mar 28 05:00:00 EDT 1920
> unicorn:~$ TZ=EST5EDT date -d '1920-03-28 +4 hours'
> Sun Mar 28 04:00:00 EST 1920
>
> There. There's a timestamp where you get a different result. I'm
> sure there are more.
>
> If being wrong about times in 1920 (and probably other years as well)
> is not acceptable to you, then you should switch to America/New_York.
>
> If the idea that you would ever CARE about the clock reading at various
> times during the 1920s is laughable to you, then do whatever you want,
> but please don't advocate that others follow your example.
Well since I am not going to set any of my systems to a time in 1920, then I believe I am save from the time machines.
I did not advocate setting the time zone to any particular one. I think you read that into my posts. Nor did I tell anyone to use a particular time zone file.
What I did post was what I use, that is not advocating anything.
The clock on all my systems is set to GMT time, so all the time zone file/data is doing is displaying the time on the desktop to local time, and for timestamps for logs, files etc.
It is definitely not worth all the paper these posts were written on.
Reply to: