Groups > linux.debian.user > #264173 > unrolled thread

ntpsec as server questions

Started by	gene heskett <gheskett@shentel.net>
First post	2023-12-04 01:50 +0100
Last post	2023-12-04 11:00 +0100
Articles	20 on this page of 99 — 17 participants

Back to article view | Back to linux.debian.user

  ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 01:50 +0100
    Re: ntpsec as server questions jeremy ardley <jeremy.ardley@gmail.com> - 2023-12-04 02:00 +0100
      Re: ntpsec as server questions jeremy ardley <jeremy.ardley@gmail.com> - 2023-12-04 02:10 +0100
        Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 10:00 +0100
          Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-04 12:00 +0100
            Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 12:40 +0100
              Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-04 13:20 +0100
                Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 17:00 +0100
                  Re: ntpsec as server questions Dan Purgert <dan@djph.net> - 2023-12-04 17:40 +0100
                    Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 22:30 +0100
                      Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-05 04:00 +0100
                  Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-04 17:40 +0100
                    Re: ntpsec as server questions Max Nikulin <manikulin@gmail.com> - 2023-12-04 18:10 +0100
                      Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-04 19:50 +0100
                        Re: ntpsec as server questions Max Nikulin <manikulin@gmail.com> - 2023-12-16 11:40 +0100
                    Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 22:30 +0100
                  Re: ntpsec as server questions John Hasler <john@sugarbit.com> - 2023-12-04 17:40 +0100
                    Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 22:40 +0100
                  Re: ntpsec as server questions Tom Furie <tom@furie.org.uk> - 2023-12-04 17:50 +0100
                Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-04 20:20 +0100
                  Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 22:40 +0100
                Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 20:20 +0100
            Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-04 13:20 +0100
              Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-04 14:00 +0100
              Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 21:30 +0100
                Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-04 21:40 +0100
                  Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-04 22:50 +0100
                  Re: ntpsec as server questions jeremy ardley <jeremy.ardley@gmail.com> - 2023-12-05 00:50 +0100
              Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 21:30 +0100
                Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-04 23:20 +0100
                  Re: ntpsec as server questions Max Nikulin <manikulin@gmail.com> - 2023-12-05 17:40 +0100
                    Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-05 18:10 +0100
                      Re: ntpsec as server questions Max Nikulin <manikulin@gmail.com> - 2023-12-06 13:30 +0100
                        Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-06 14:10 +0100
                          Re: ntpsec as server questions Max Nikulin <manikulin@gmail.com> - 2023-12-06 16:10 +0100
                            Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-06 16:50 +0100
                              Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-06 17:20 +0100
                                Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-06 17:30 +0100
                                  Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-06 17:50 +0100
                                Re: ntpsec as server questions Curt <curty@free.fr> - 2023-12-06 17:50 +0100
                    Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-05 18:30 +0100
                      Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-05 18:30 +0100
                    Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-06 06:30 +0100
                      Re: ntpsec as server questions Max Nikulin <manikulin@gmail.com> - 2023-12-06 17:50 +0100
                        Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-06 18:10 +0100
                          Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-06 18:30 +0100
                            Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-06 18:40 +0100
                        Re: ntpsec as server questions Curt <curty@free.fr> - 2023-12-06 18:50 +0100
                          Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-06 19:00 +0100
                            Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-06 19:10 +0100
                              Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-06 19:30 +0100
                                Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-06 21:50 +0100
                                  Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-07 00:20 +0100
                                    Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-07 01:20 +0100
                                      Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-07 01:30 +0100
                                        Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-07 01:30 +0100
                                          Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-07 01:40 +0100
                                            Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-07 01:50 +0100
                                              Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-07 02:50 +0100
                                                Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-07 06:50 +0100
                                    Re: ntpsec as server questions Max Nikulin <manikulin@gmail.com> - 2023-12-08 03:40 +0100
                                      Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-08 04:10 +0100
                                        Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-08 05:20 +0100
                                          Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-08 13:20 +0100
                                            Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-08 18:00 +0100
                                            Re: ntpsec as server questions Max Nikulin <manikulin@gmail.com> - 2023-12-09 12:20 +0100
                                          Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-08 13:40 +0100
                                            Re: ntpsec as server questions <tomas@tuxteam.de> - 2023-12-08 14:20 +0100
                                            Re: ntpsec as server questions "Thomas Schmitt" <scdbackup@gmx.net> - 2023-12-08 14:40 +0100
                                        Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-08 18:10 +0100
                              Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-06 21:30 +0100
                                Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-07 00:20 +0100
                                  Re: ntpsec as server questions <tomas@tuxteam.de> - 2023-12-07 06:40 +0100
                                  Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-07 06:50 +0100
                                    Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-07 13:20 +0100
                                      Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-07 14:10 +0100
                                      Re: ntpsec as server questions John Hasler <john@sugarbit.com> - 2023-12-07 15:30 +0100
                                        Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-07 15:40 +0100
                                          Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-07 17:00 +0100
                                        Local time in databases (Re: ntpsec as server questions) Max Nikulin <manikulin@gmail.com> - 2023-12-07 16:40 +0100
                                          Re: Local time in databases (Re: ntpsec as server questions) <tomas@tuxteam.de> - 2023-12-07 17:10 +0100
                                            Re: Local time in databases (Re: ntpsec as server questions) Max Nikulin <manikulin@gmail.com> - 2023-12-08 03:20 +0100
                                              Re: Local time in databases (Re: ntpsec as server questions) Nicholas Geovanis <nickgeovanis@gmail.com> - 2023-12-08 05:20 +0100
                                                Re: Local time in databases (Re: ntpsec as server questions) <tomas@tuxteam.de> - 2023-12-08 05:40 +0100
                                                  Re: Local time in databases (Re: ntpsec as server questions) Max Nikulin <manikulin@gmail.com> - 2023-12-12 18:10 +0100
                                                    Re: Local time in databases David Wright <deblis@lionunicorn.co.uk> - 2023-12-17 06:20 +0100
                                              Re: Local time in databases (Re: ntpsec as server questions) <tomas@tuxteam.de> - 2023-12-08 05:40 +0100
                            Re: ntpsec as server questions James Cloos <cloos@jhcloos.com> - 2023-12-06 22:30 +0100
                              Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-07 06:50 +0100
                Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-05 04:00 +0100
        Re: ntpsec as server questions Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2023-12-04 11:10 +0100
          Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 12:30 +0100
            Re: ntpsec as server questions <tomas@tuxteam.de> - 2023-12-04 12:50 +0100
    Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-04 02:00 +0100
    Re: ntpsec as server questions <tomas@tuxteam.de> - 2023-12-04 06:10 +0100
      Re: ntpsec as server questions Jeffrey Walton <noloader@gmail.com> - 2023-12-04 06:30 +0100
        Re: ntpsec as server questions Charles Curley <charlescurley@charlescurley.com> - 2023-12-04 07:30 +0100
          Re: ntpsec as server questions Jeffrey Walton <noloader@gmail.com> - 2023-12-04 08:10 +0100
      Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 11:00 +0100

Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →

#264301

From	gene heskett <gheskett@shentel.net>
Date	2023-12-05 18:30 +0100
Message-ID	<HHHp7-brZr-11@gated-at.bofh.it>
In reply to	#264297

On 12/5/23 11:38, Max Nikulin wrote:
> 
> On 05/12/2023 05:14, Pocket wrote:
>> For 
>> gene..................................................................
> [...]
>> zone=EST5EDT
>> zoneinfo=/usr/share/zoneinfo
>> localtime=/etc/localtime
>> timezone=/etc/timezone
>> profile=/etc/profile.d
>> if [ -e "$zoneinfo"/"$zone" ];then
>>      ln -sf "$zoneinfo"/"$zone" "$localtime"
>> else
>>      printf "%s\n" "Invalid zone: $zoneinfo/$zone"
>>      exit 1
>> fi
>> printf "%s\n" "$zone" > "$timezone"
>> printf "%s\n" "TZ=$zone;export TZ" > "$profile"/timezone.sh
> 
> To set /etc/localtime and /etc/timezone I would recommend the command 
> that has been repeated several times in this thread:
> 
>       dpkg-reconfigure tzdata
> 
That was not tried.
> And I would recommend against setting the TZ environment variable unless 
> it is really necessary. If somebody needs it then it is better to do it 
> in /etc/environment.d as well. KDE has its own GUI to set user-specific 
> timezone, but I am unsure if selected value will be applied in the case 
> of console or ssh login.
> 
> I am surprised that POSIX EST5EDT timezone has irregularities at least 
> as it is implemented in GNU libc. I believed that it specifies just 
> standard and summer time.
> 
Both America/New_York and the ESTSEDT methods are available on this 
elderly buster install. tzselect outputs the America/ version.

In retrospect, I think making /etc/localtime a link to /etc/timezone 
would probably have made this endless thread moot.  That would work 
until some update which will never happen now, deletes /etc/timezone.

The education of Gene continues... I've learned a lot.  Thank you all.

Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

[toc] | [prev] | [next] | [standalone]

#264302

From	Pocket <pocket@columbus.rr.com>
Date	2023-12-05 18:30 +0100
Message-ID	<HHHp7-brZr-17@gated-at.bofh.it>
In reply to	#264301

On 12/5/23 12:21, gene heskett wrote:
> On 12/5/23 11:38, Max Nikulin wrote:
>>
>> On 05/12/2023 05:14, Pocket wrote:
>>> For 
>>> gene..................................................................
>> [...]
>>> zone=EST5EDT
>>> zoneinfo=/usr/share/zoneinfo
>>> localtime=/etc/localtime
>>> timezone=/etc/timezone
>>> profile=/etc/profile.d
>>> if [ -e "$zoneinfo"/"$zone" ];then
>>>      ln -sf "$zoneinfo"/"$zone" "$localtime"
>>> else
>>>      printf "%s\n" "Invalid zone: $zoneinfo/$zone"
>>>      exit 1
>>> fi
>>> printf "%s\n" "$zone" > "$timezone"
>>> printf "%s\n" "TZ=$zone;export TZ" > "$profile"/timezone.sh
>>
>> To set /etc/localtime and /etc/timezone I would recommend the command 
>> that has been repeated several times in this thread:
>>
>>       dpkg-reconfigure tzdata
>>
> That was not tried.


And won't work if you want to use a POSIX time zone


>> And I would recommend against setting the TZ environment variable 
>> unless it is really necessary. If somebody needs it then it is better 
>> to do it in /etc/environment.d as well. KDE has its own GUI to set 
>> user-specific timezone, but I am unsure if selected value will be 
>> applied in the case of console or ssh login.
>>
>> I am surprised that POSIX EST5EDT timezone has irregularities at 
>> least as it is implemented in GNU libc. I believed that it specifies 
>> just standard and summer time.
>>
> Both America/New_York and the ESTSEDT methods are available on this 
> elderly buster install. tzselect outputs the America/ version.
>
> In retrospect, I think making /etc/localtime a link to /etc/timezone 
> would probably have made this endless thread moot. That would work 
> until some update which will never happen now, deletes /etc/timezone.


That should not be done.

/etc/timezone contains the name (filespec) of the time zone not a 
"pointer" to the time zone file


>
> The education of Gene continues... I've learned a lot.  Thank you all.
>
> Cheers, Gene Heskett.

-- 
It's not easy to be me

[toc] | [prev] | [next] | [standalone]

#264317

From	David Wright <deblis@lionunicorn.co.uk>
Date	2023-12-06 06:30 +0100
Message-ID	<HHSDT-bBsb-1@gated-at.bofh.it>
In reply to	#264297

On Tue 05 Dec 2023 at 23:37:31 (+0700), Max Nikulin wrote:
> On 05/12/2023 05:14, Pocket wrote:
> > For gene..................................................................
> [...]
> > zone=EST5EDT
> > zoneinfo=/usr/share/zoneinfo
> > localtime=/etc/localtime
> > timezone=/etc/timezone
> > profile=/etc/profile.d
> > if [ -e "$zoneinfo"/"$zone" ];then
> >      ln -sf "$zoneinfo"/"$zone" "$localtime"
> > else
> >      printf "%s\n" "Invalid zone: $zoneinfo/$zone"
> >      exit 1
> > fi
> > printf "%s\n" "$zone" > "$timezone"
> > printf "%s\n" "TZ=$zone;export TZ" > "$profile"/timezone.sh
> 
> To set /etc/localtime and /etc/timezone I would recommend the command
> that has been repeated several times in this thread:
> 
>      dpkg-reconfigure tzdata
> 
> And I would recommend against setting the TZ environment variable
> unless it is really necessary. If somebody needs it then it is better
> to do it in /etc/environment.d as well. KDE has its own GUI to set
> user-specific timezone, but I am unsure if selected value will be
> applied in the case of console or ssh login.
> 
> I am surprised that POSIX EST5EDT timezone has irregularities at least
> as it is implemented in GNU libc. I believed that it specifies just
> standard and summer time.

During WWII they had War Time, just as Britain had Double Summer Time,
with Summer Time through the winters.

  $ for j in America/New_York EST5EDT Europe/London;\
  > do TZ="$j" date -d @$(TZ=UT date +'%s' -d '1940-01-01'); done
  Sun Dec 31 19:00:00 EST 1939
  Sun Dec 31 19:00:00 EST 1939
  Mon Jan  1 00:00:00 GMT 1940
  $ for j in America/New_York EST5EDT Europe/London;\
  > do TZ="$j" date -d @$(TZ=UT date +'%s' -d '1943-01-01'); done
  Thu Dec 31 20:00:00 EWT 1942
  Thu Dec 31 20:00:00 EWT 1942
  Fri Jan  1 01:00:00 BST 1943
  $ for j in America/New_York EST5EDT Europe/London;\
  > do TZ="$j" date -d @$(TZ=UT date +'%s' -d '1943-06-01'); done
  Mon May 31 20:00:00 EWT 1943
  Mon May 31 20:00:00 EWT 1943
  Tue Jun  1 02:00:00 BDST 1943
  $ 

But there are periods when the timezones America/New_York and EST5EDT
diverge:

  $ for j in America/New_York EST5EDT;\
  > do TZ="$j" date -d @$(TZ=UT date +'%s' -d '1966-06-24');done
  Thu Jun 23 20:00:00 EDT 1966
  Thu Jun 23 19:00:00 EST 1966
  $

> However since these rules are specific to US, I would prefer IANA
> identifiers like America/New_York.

I don't know who maintains the legacy EST5EDT zone, or for whom;
the quotation below suggests that it may just follow New Jersey.
For a long period after the war, it seems the timezones in the US
were all over the place.

> https://naggum.no/lugm-time.html
> Erik Naggum. A Long, Painful History of Time. 1999
> > 8.2 Timezone Representation
> > 
> > David Ols[o]n of Digital Equipment Corporation has laid down a tremendous
> > amount of work in collecting the timezones of the world and their
> > daylight saving time boundaries. Contrary to the Unix System V approach
> > from New Jersey (insert appropriate booing for best effect), which
> > codifies a daylight saving time regime only for the current year, and
> > apply it to all years, David Ols[o]n's approach is to maintain tables of
> > all the timezone changes.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#264340

From	Max Nikulin <manikulin@gmail.com>
Date	2023-12-06 17:50 +0100
Message-ID	<HI3fX-bKeG-1@gated-at.bofh.it>
In reply to	#264317

On 06/12/2023 12:22, David Wright wrote:
> On Tue 05 Dec 2023 at 23:37:31 (+0700), Max Nikulin wrote:
>> I am surprised that POSIX EST5EDT timezone has irregularities at least
>> as it is implemented in GNU libc. I believed that it specifies just
>> standard and summer time.
> 
> During WWII they had War Time, just as Britain had Double Summer Time,
> with Summer Time through the winters.

I was aware of special DST rules during WWII, but I did not expect that 
"EST5EDT" may include any historical data. Certainly it does not 
explicitly specify days when summer time is effective, just 
abbreviations "EST" and "EDT" with time offset of 5 hours behind UTC for 
"EST". Partial time transition history is new for me for these kind of 
time zones.

https://en.wikipedia.org/wiki/Daylight_saving_time_in_the_United_States
is a long enough article.

> I don't know who maintains the legacy EST5EDT zone, or for whom;
> the quotation below suggests that it may just follow New Jersey.
> For a long period after the war, it seems the timezones in the US
> were all over the place.

https://data.iana.org/time-zones/theory.html :
> Older versions of this package defined legacy names that are
> incompatible with the first guideline of location names, but which are
> still supported. These legacy names are mostly defined in the file
> 'etcetera'. Also, the file 'backward' defines the legacy names
> 'Etc/GMT0', 'Etc/GMT-0', 'Etc/GMT+0', 'GMT0', 'GMT-0' and 'GMT+0', and
> the file 'northamerica' defines the legacy names 'EST5EDT', 'CST6CDT',
> 'MST7MDT', and 'PST8PDT'.
[...]
> POSIX does not define the DST transitions for TZ values like "EST5EDT".
> Traditionally the current US DST rules were used to interpret such
> values, but this meant that the US DST rules were compiled into each
> time conversion package, and when US time conversion rules changed (as
> in the United States in 1987 and again in 2007), all packages that
> interpreted TZ values had to be updated to ensure proper results.

My reading of this document is that EST5EDT file in tzdata is a POSIX 
extension, not "true" POSIX.

A lot of details concerning database contents are given if files like
https://github.com/eggert/tz/blob/main/northamerica

I have not noticed any America/* timezone that strictly follows EST5EDT.

[toc] | [prev] | [next] | [standalone]

#264343

From	Pocket <pocket@columbus.rr.com>
Date	2023-12-06 18:10 +0100
Message-ID	<HI3zk-bKHr-7@gated-at.bofh.it>
In reply to	#264340

On 12/6/23 11:42, Max Nikulin wrote:
> On 06/12/2023 12:22, David Wright wrote:
>> On Tue 05 Dec 2023 at 23:37:31 (+0700), Max Nikulin wrote:
>>> I am surprised that POSIX EST5EDT timezone has irregularities at least
>>> as it is implemented in GNU libc. I believed that it specifies just
>>> standard and summer time.
>>
>> During WWII they had War Time, just as Britain had Double Summer Time,
>> with Summer Time through the winters.
>
> I was aware of special DST rules during WWII, but I did not expect 
> that "EST5EDT" may include any historical data. Certainly it does not 
> explicitly specify days when summer time is effective, just 
> abbreviations "EST" and "EDT" with time offset of 5 hours behind UTC 
> for "EST". Partial time transition history is new for me for these 
> kind of time zones.
>
> https://en.wikipedia.org/wiki/Daylight_saving_time_in_the_United_States
> is a long enough article.
>
>> I don't know who maintains the legacy EST5EDT zone, or for whom;
>> the quotation below suggests that it may just follow New Jersey.
>> For a long period after the war, it seems the timezones in the US
>> were all over the place.
>
> https://data.iana.org/time-zones/theory.html :
>> Older versions of this package defined legacy names that are
>> incompatible with the first guideline of location names, but which are
>> still supported. These legacy names are mostly defined in the file
>> 'etcetera'. Also, the file 'backward' defines the legacy names
>> 'Etc/GMT0', 'Etc/GMT-0', 'Etc/GMT+0', 'GMT0', 'GMT-0' and 'GMT+0', and
>> the file 'northamerica' defines the legacy names 'EST5EDT', 'CST6CDT',
>> 'MST7MDT', and 'PST8PDT'.
> [...]
>> POSIX does not define the DST transitions for TZ values like "EST5EDT".
>> Traditionally the current US DST rules were used to interpret such
>> values, but this meant that the US DST rules were compiled into each
>> time conversion package, and when US time conversion rules changed (as
>> in the United States in 1987 and again in 2007), all packages that
>> interpreted TZ values had to be updated to ensure proper results.
>
> My reading of this document is that EST5EDT file in tzdata is a POSIX 
> extension, not "true" POSIX.
>
> A lot of details concerning database contents are given if files like
> https://github.com/eggert/tz/blob/main/northamerica
>
> I have not noticed any America/* timezone that strictly follows EST5EDT.


 From the README

The information in the time zone data files is by no means authoritative;
fixes and enhancements are welcome.  Please see the file CONTRIBUTING
for details

I take that as chaos reins supreme and one zone is no better or worst 
that the other(s)

IE there is no "standard"


-- 
It's not easy to be me

[toc] | [prev] | [next] | [standalone]

#264344

From	Greg Wooledge <greg@wooledge.org>
Date	2023-12-06 18:30 +0100
Message-ID	<HI3SF-bKTC-5@gated-at.bofh.it>
In reply to	#264343

On Wed, Dec 06, 2023 at 12:06:04PM -0500, Pocket wrote:
> From the README
> 
> The information in the time zone data files is by no means authoritative;
> fixes and enhancements are welcome.  Please see the file CONTRIBUTING
> for details
> 
> I take that as chaos reins supreme and one zone is no better or worst that
> the other(s)
> 
> IE there is no "standard"

The standards are determined by government entities.  The question is
how accurately a given time zone reflects the decisions made by the
government entities within a given political space.

If America/New_York more accurately describes the tracking of political
timekeeping within the Eastern part of the United States (with specific
exceptions, e.g. Kentucky) than EST5EDT does, then America/New_York
should be preferred for most purposes.

[toc] | [prev] | [next] | [standalone]

#264345

From	Pocket <pocket@columbus.rr.com>
Date	2023-12-06 18:40 +0100
Message-ID	<HI42l-bKZB-15@gated-at.bofh.it>
In reply to	#264344

On 12/6/23 12:24, Greg Wooledge wrote:
> On Wed, Dec 06, 2023 at 12:06:04PM -0500, Pocket wrote:
>>  From the README
>>
>> The information in the time zone data files is by no means authoritative;
>> fixes and enhancements are welcome.  Please see the file CONTRIBUTING
>> for details
>>
>> I take that as chaos reins supreme and one zone is no better or worst that
>> the other(s)
>>
>> IE there is no "standard"
> The standards are determined by government entities.  The question is
> how accurately a given time zone reflects the decisions made by the
> government entities within a given political space.
>
> If America/New_York more accurately describes the tracking of political
> timekeeping within the Eastern part of the United States (with specific
> exceptions, e.g. Kentucky) than EST5EDT does, then America/New_York
> should be preferred for most purposes.
>
Well I have used EST5DST for many years, maybe decades and I have yet to have an issue with it, so I wouldn't want to "prefer" America/New_York over EST5DST.

I haven't found any thing to bump me into changing the time zone file.
Until I have issues with it I will continue to use it.

If it ain't broke don't fix it.


-- 
It's not easy to be me

[toc] | [prev] | [next] | [standalone]

#264346

From	Curt <curty@free.fr>
Date	2023-12-06 18:50 +0100
Message-ID	<HI4c2-bL69-5@gated-at.bofh.it>
In reply to	#264340

On 2023-12-06, Max Nikulin <manikulin@gmail.com> wrote:
>
> My reading of this document is that EST5EDT file in tzdata is a POSIX 
> extension, not "true" POSIX.
>

 POSIX format specification

 The POSIX time zone format is the traditionally used format for AIX systems and
 provides a slight performance advantage over the Olson time zone format.
 Example of a POSIX format is EST5EDT.

 The advantage of POSIX is that you can easily and explicitly specify the time
 zone and daylight saving time (DST) details manually, however you wish. The
 performance of applications that call time functions will be faster than using
 Olson specification. And whenever a nation's government decides to change its
 DST rules, the POSIX format is simpler because we can simply change the
 variable definition. There is no need to install any new patch to update time
 database files, as Olson requires.

Does this apply to "us?"

https://developer.ibm.com/articles/au-aix-posix/

[toc] | [prev] | [next] | [standalone]

#264347

From	Greg Wooledge <greg@wooledge.org>
Date	2023-12-06 19:00 +0100
Message-ID	<HI4lH-bLc9-13@gated-at.bofh.it>
In reply to	#264346

On Wed, Dec 06, 2023 at 05:40:00PM -0000, Curt wrote:
>  POSIX format specification
> 
>  The POSIX time zone format is the traditionally used format for AIX systems and
>  provides a slight performance advantage over the Olson time zone format.
>  Example of a POSIX format is EST5EDT.
> 
>  The advantage of POSIX is that you can easily and explicitly specify the time
>  zone and daylight saving time (DST) details manually, however you wish. The
>  performance of applications that call time functions will be faster than using
>  Olson specification. And whenever a nation's government decides to change its
>  DST rules, the POSIX format is simpler because we can simply change the
>  variable definition. There is no need to install any new patch to update time
>  database files, as Olson requires.
> 
> Does this apply to "us?"
> 
> https://developer.ibm.com/articles/au-aix-posix/

This does *not* describe how Debian's EST5EDT, and similarly named
zones, work.  Debian's time zones use a database of DST transition
periods -- all of them, even EST5EDT.  It's just a different set of
transitions than America/New_York uses.

Also, you snipped the rest of that section:

  The disadvantage of this approach is that it cannot track the history
  of timezone-related changes and it is not easy to read as it looks
  cryptic. When a government changes the rules and you update your time
  zone (TZ) variable, it is assumed to be the same DST rule for all
  years past and future.

That's a fairly important paragraph.

Applying the same rules to a timestamp in 2023 and a timestamp in 2006
may give incorrect results, as the DST rules in the US changed in 2007.
That's why the method described by this AIX manual is no longer in
common use.

[toc] | [prev] | [next] | [standalone]

#264348

From	Pocket <pocket@columbus.rr.com>
Date	2023-12-06 19:10 +0100
Message-ID	<HI4vn-bLxi-11@gated-at.bofh.it>
In reply to	#264347

On 12/6/23 12:55, Greg Wooledge wrote:
> On Wed, Dec 06, 2023 at 05:40:00PM -0000, Curt wrote:
>>   POSIX format specification
>>
>>   The POSIX time zone format is the traditionally used format for AIX systems and
>>   provides a slight performance advantage over the Olson time zone format.
>>   Example of a POSIX format is EST5EDT.
>>
>>   The advantage of POSIX is that you can easily and explicitly specify the time
>>   zone and daylight saving time (DST) details manually, however you wish. The
>>   performance of applications that call time functions will be faster than using
>>   Olson specification. And whenever a nation's government decides to change its
>>   DST rules, the POSIX format is simpler because we can simply change the
>>   variable definition. There is no need to install any new patch to update time
>>   database files, as Olson requires.
>>
>> Does this apply to "us?"
>>
>> https://developer.ibm.com/articles/au-aix-posix/
> This does *not* describe how Debian's EST5EDT, and similarly named
> zones, work.  Debian's time zones use a database of DST transition
> periods -- all of them, even EST5EDT.  It's just a different set of
> transitions than America/New_York uses.
>
> Also, you snipped the rest of that section:
>
>    The disadvantage of this approach is that it cannot track the history
>    of timezone-related changes and it is not easy to read as it looks
>    cryptic. When a government changes the rules and you update your time
>    zone (TZ) variable, it is assumed to be the same DST rule for all
>    years past and future.
>
> That's a fairly important paragraph.
>
> Applying the same rules to a timestamp in 2023 and a timestamp in 2006
> may give incorrect results, as the DST rules in the US changed in 2007.
> That's why the method described by this AIX manual is no longer in
> common use.
>
TZ=POSIX;date
Wed Dec  6 18:00:38 POSIX 2023

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?

-- 
It's not easy to be me

[toc] | [prev] | [next] | [standalone]

#264350

From	Greg Wooledge <greg@wooledge.org>
Date	2023-12-06 19:30 +0100
Message-ID	<HI4OK-bLIF-9@gated-at.bofh.it>
In reply to	#264348

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.

[toc] | [prev] | [next] | [standalone]

#264353

From	David Wright <deblis@lionunicorn.co.uk>
Date	2023-12-06 21:50 +0100
Message-ID	<HI70e-bNxW-5@gated-at.bofh.it>
In reply to	#264350

On Wed 06 Dec 2023 at 13:27:40 (-0500), Greg Wooledge 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

AAAAAAAA

> 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

BBBBBBBB

> 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

CCCCCCCC

> 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.

Comparing zdump -v America/New_York | cut -b 19- > /tmp/a-ny
with      zdump -v EST5EDT | cut -b 10- > /tmp/e5e

shows that the former starts at 1883 (no changes then until 1918,
AAAAAAAA above), and the latter omits the period 1920–1966, except
for War Time and Peace Time (between BBBBBBBB and CCCCCCCC).

I've expanded my guesses as to why. I had thought that it might be
because the "Unix System V approach from New Jersey (insert
appropriate booing for best effect)" implied that NJ didn't observe
DST over that period, but perhaps it's just that there's no way to
determine single dates for changing the clocks.

 "Having rallied the general public's support, the Time Uniformity
 Committee's goal was accomplished, but only after discovering and
 disclosing that on the 35-mile stretch of highway (Route 2) between
 Moundsville, W.V., and Steubenville, Ohio, every bus driver and his
 passengers had to endure seven time changes!"

 https://www.webexhibits.org//daylightsaving/e.html

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#264362

From	Pocket <pocket@columbus.rr.com>
Date	2023-12-07 00:20 +0100
Message-ID	<HI9ln-bPbg-1@gated-at.bofh.it>
In reply to	#264353

On 12/6/23 15:41, David Wright wrote:
> On Wed 06 Dec 2023 at 13:27:40 (-0500), Greg Wooledge 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
> AAAAAAAA
>
>> 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
> BBBBBBBB
>
>> 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
> CCCCCCCC
>
>> 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.
> Comparing zdump -v America/New_York | cut -b 19- > /tmp/a-ny
> with      zdump -v EST5EDT | cut -b 10- > /tmp/e5e
>
> shows that the former starts at 1883 (no changes then until 1918,
> AAAAAAAA above), and the latter omits the period 1920–1966, except
> for War Time and Peace Time (between BBBBBBBB and CCCCCCCC).

Because DST was not in force/usage except the metro NYC. Every where 
else didn't use/have it.

That makes EST5DST correct except for NYC and America/New_York 
completely incorrect except of course NYC.

Which is why I prefer to use EST5DST


BTW there isn't any timezone called America/New_York, it is or course 
the Eastern Standard Time Zone.

America/New_your should actually be called America/Eastern.  The POSIX 
EST5DST is closer to being correct.


>
> I've expanded my guesses as to why. I had thought that it might be
> because the "Unix System V approach from New Jersey (insert
> appropriate booing for best effect)" implied that NJ didn't observe
> DST over that period, but perhaps it's just that there's no way to
> determine single dates for changing the clocks.
>
>   "Having rallied the general public's support, the Time Uniformity
>   Committee's goal was accomplished, but only after discovering and
>   disclosing that on the 35-mile stretch of highway (Route 2) between
>   Moundsville, W.V., and Steubenville, Ohio, every bus driver and his
>   passengers had to endure seven time changes!"
>
>   https://www.webexhibits.org//daylightsaving/e.html
>
> Cheers,
> David.
>
-- 
It's not easy to be me

[toc] | [prev] | [next] | [standalone]

#264365

From	Greg Wooledge <greg@wooledge.org>
Date	2023-12-07 01:20 +0100
Message-ID	<HIahr-bPJt-1@gated-at.bofh.it>
In reply to	#264362

On Wed, Dec 06, 2023 at 06:11:16PM -0500, Pocket wrote:
> Because DST was not in force/usage except the metro NYC. Every where else
> didn't use/have it.
> 
> That makes EST5DST correct except for NYC and America/New_York completely
> incorrect except of course NYC.

(EST5EDT not EST5DST.)  Now this is interesting.  If the America/New_York
zone definition is *wrong* for me, then I'd like to use one that's less
wrong.  Is there an "Olson format" time zone definition that's actually
correct for cities like... Cleveland, just as a random example?

I found
<https://www.convertit.com/Go/ConvertIt/World_Time/Current_Time.ASP?For=Cleveland+Ohio+United+States>
which says that Cleveland is using America/New_York ... and basically
all the other web sites I've found either show just the current time
(gee thanks, I knew the *current* time), or they only have data back
to 1970, like <https://www.timeanddate.com/time/zone/usa/cleveland>.

Looking at the actual tzdata source, as present in Debian
<https://salsa.debian.org/glibc-team/tzdata/-/blob/sid/northamerica>
I see the following comments:

# US eastern time, represented by New York

# Connecticut, Delaware, District of Columbia, most of Florida,
# Georgia, southeast Indiana (Dearborn and Ohio counties), eastern Kentucky
# (except America/Kentucky/Louisville below), Maine, Maryland, Massachusetts,
# New Hampshire, New Jersey, New York, North Carolina, Ohio,
# Pennsylvania, Rhode Island, South Carolina, eastern Tennessee,
# Vermont, Virginia, West Virginia

So, basically every reference I can find, and every reference I've *ever*
found, other than Pocket's email, has said that America/New_York is
correct for me.

[toc] | [prev] | [next] | [standalone]

#264366

From	Pocket <pocket@columbus.rr.com>
Date	2023-12-07 01:30 +0100
Message-ID	<HIar7-bPMq-3@gated-at.bofh.it>
In reply to	#264365

On 12/6/23 19:12, Greg Wooledge wrote:
> On Wed, Dec 06, 2023 at 06:11:16PM -0500, Pocket wrote:
>> Because DST was not in force/usage except the metro NYC. Every where else
>> didn't use/have it.
>>
>> That makes EST5DST correct except for NYC and America/New_York completely
>> incorrect except of course NYC.
> (EST5EDT not EST5DST.)  Now this is interesting.  If the America/New_York
> zone definition is *wrong* for me, then I'd like to use one that's less
> wrong.  Is there an "Olson format" time zone definition that's actually
> correct for cities like... Cleveland, just as a random example?
>
> I found
> <https://www.convertit.com/Go/ConvertIt/World_Time/Current_Time.ASP?For=Cleveland+Ohio+United+States>
> which says that Cleveland is using America/New_York ... and basically
> all the other web sites I've found either show just the current time
> (gee thanks, I knew the *current* time), or they only have data back
> to 1970, like <https://www.timeanddate.com/time/zone/usa/cleveland>.
>
> Looking at the actual tzdata source, as present in Debian
> <https://salsa.debian.org/glibc-team/tzdata/-/blob/sid/northamerica>
> I see the following comments:
>
> # US eastern time, represented by New York
>
> # Connecticut, Delaware, District of Columbia, most of Florida,
> # Georgia, southeast Indiana (Dearborn and Ohio counties), eastern Kentucky
> # (except America/Kentucky/Louisville below), Maine, Maryland, Massachusetts,
> # New Hampshire, New Jersey, New York, North Carolina, Ohio,
> # Pennsylvania, Rhode Island, South Carolina, eastern Tennessee,
> # Vermont, Virginia, West Virginia
>
> So, basically every reference I can find, and every reference I've *ever*
> found, other than Pocket's email, has said that America/New_York is
> correct for me.
>
See my other post


-- 
It's not easy to be me

[toc] | [prev] | [next] | [standalone]

#264367

From	Greg Wooledge <greg@wooledge.org>
Date	2023-12-07 01:30 +0100
Message-ID	<HIar7-bPMq-5@gated-at.bofh.it>
In reply to	#264366

On Wed, Dec 06, 2023 at 07:23:18PM -0500, Pocket wrote:
> On 12/6/23 19:12, Greg Wooledge wrote:
> > So, basically every reference I can find, and every reference I've *ever*
> > found, other than Pocket's email, has said that America/New_York is
> > correct for me.
> > 
> See my other post

[citation needed]

[toc] | [prev] | [next] | [standalone]

#264369

From	Pocket <pocket@columbus.rr.com>
Date	2023-12-07 01:40 +0100
Message-ID	<HIaAO-bPPx-9@gated-at.bofh.it>
In reply to	#264367

On 12/6/23 19:26, Greg Wooledge wrote:
> On Wed, Dec 06, 2023 at 07:23:18PM -0500, Pocket wrote:
>> On 12/6/23 19:12, Greg Wooledge wrote:
>>> So, basically every reference I can find, and every reference I've *ever*
>>> found, other than Pocket's email, has said that America/New_York is
>>> correct for me.
>>>
>> See my other post
> [citation needed]
>
See my other post

-- 
It's not easy to be me

[toc] | [prev] | [next] | [standalone]

#264370

From	Greg Wooledge <greg@wooledge.org>
Date	2023-12-07 01:50 +0100
Message-ID	<HIaKt-bPSQ-3@gated-at.bofh.it>
In reply to	#264369

On Wed, Dec 06, 2023 at 07:37:32PM -0500, Pocket wrote:
> 
> On 12/6/23 19:26, Greg Wooledge wrote:
> > On Wed, Dec 06, 2023 at 07:23:18PM -0500, Pocket wrote:
> > > On 12/6/23 19:12, Greg Wooledge wrote:
> > > > So, basically every reference I can find, and every reference I've *ever*
> > > > found, other than Pocket's email, has said that America/New_York is
> > > > correct for me.
> > > > 
> > > See my other post
> > [citation needed]
> > 
> See my other post

If you mean <https://lists.debian.org/debian-user/2023/12/msg00376.html>
there are zero URLs in your text.  "Someone named Pocket said so" is not a
strong enough assertion for me to reject every other source citation
I've found.

[toc] | [prev] | [next] | [standalone]

#264372

From	Pocket <pocket@columbus.rr.com>
Date	2023-12-07 02:50 +0100
Message-ID	<HIbGx-bQr9-3@gated-at.bofh.it>
In reply to	#264370

[Multipart message — attachments visible in raw view] — view raw

On 12/6/23 19:46, Greg Wooledge wrote:
> On Wed, Dec 06, 2023 at 07:37:32PM -0500, Pocket wrote:
>> On 12/6/23 19:26, Greg Wooledge wrote:
>>> On Wed, Dec 06, 2023 at 07:23:18PM -0500, Pocket wrote:
>>>> On 12/6/23 19:12, Greg Wooledge wrote:
>>>>> So, basically every reference I can find, and every reference I've *ever*
>>>>> found, other than Pocket's email, has said that America/New_York is
>>>>> correct for me.
>>>>>
>>>> See my other post
>>> [citation needed]
>>>
>> See my other post
> If you mean<https://lists.debian.org/debian-user/2023/12/msg00376.html>
> there are zero URLs in your text.  "Someone named Pocket said so" is not a
> strong enough assertion for me to reject every other source citation
> I've found.
>
Start Here

The *Standard Time Act* of 1918, also known as the *Calder Act*, was the 
first United States <https://en.wikipedia.org/wiki/United_States> 
federal law implementing Standard time 
<https://en.wikipedia.org/wiki/Standard_time#North_America> and Daylight 
saving time in the United States 
<https://en.wikipedia.org/wiki/Daylight_saving_time_in_the_United_States>.^[2] 
<https://en.wikipedia.org/wiki/Standard_Time_Act#cite_note-2> It defined 
five time zones for the United States and authorized the Interstate 
Commerce Commission 
<https://en.wikipedia.org/wiki/Interstate_Commerce_Commission> to define 
the limits of each time zone.

The section concerning daylight saving time was repealed by the act 
titled /An Act For the repeal of the daylight-saving law/, Pub. L. 
<https://en.wikipedia.org/wiki/Public_Law_(United_States)>Tooltip Public 
Law (United States) 66–40 
<https://uslaw.link/citation/us-law/public/66/40>, 41 Stat. 
<https://en.wikipedia.org/wiki/United_States_Statutes_at_Large> 280 
<https://legislink.org/us/stat-41-280>, enacted August 20, 1919, over 
President Woodrow Wilson 
<https://en.wikipedia.org/wiki/Woodrow_Wilson>'s veto.

Section 264 of the act mistakenly placed most of the state of Idaho 
<https://en.wikipedia.org/wiki/Idaho> (south of the Salmon River 
<https://en.wikipedia.org/wiki/Salmon_River_(Idaho)>) in UTC−06:00 
<https://en.wikipedia.org/wiki/UTC%E2%88%9206:00> CST (Central Standard 
Time <https://en.wikipedia.org/wiki/Central_Standard_Time>), but was 
amended in 2007 by Congress to UTC−07:00 
<https://en.wikipedia.org/wiki/UTC%E2%88%9207:00> MST (Mountain Standard 
Time <https://en.wikipedia.org/wiki/Mountain_Standard_Time>).^[3] 
<https://en.wikipedia.org/wiki/Standard_Time_Act#cite_note-google-3> MST 
was observed prior to the correction.

-- 
It's not easy to be me

[toc] | [prev] | [next] | [standalone]

#264376

From	David Wright <deblis@lionunicorn.co.uk>
Date	2023-12-07 06:50 +0100
Message-ID	<HIfqN-bSNR-3@gated-at.bofh.it>
In reply to	#264372

On Wed 06 Dec 2023 at 20:44:29 (-0500), Pocket wrote:
> On 12/6/23 19:46, Greg Wooledge wrote:
> > On Wed, Dec 06, 2023 at 07:37:32PM -0500, Pocket wrote:
> > > On 12/6/23 19:26, Greg Wooledge wrote:
> > > > On Wed, Dec 06, 2023 at 07:23:18PM -0500, Pocket wrote:
> > > > > On 12/6/23 19:12, Greg Wooledge wrote:
> > > > > > So, basically every reference I can find, and every reference I've *ever*
> > > > > > found, other than Pocket's email, has said that America/New_York is
> > > > > > correct for me.
> > > > > > 
> > > > > See my other post
> > > > [citation needed]
> > > > 
> > > See my other post
> > If you mean<https://lists.debian.org/debian-user/2023/12/msg00376.html>
> > there are zero URLs in your text.  "Someone named Pocket said so" is not a
> > strong enough assertion for me to reject every other source citation
> > I've found.
> > 
> Start Here
> 
> The *Standard Time Act* of 1918, also known as the *Calder Act*, was
> the first United States <https://en.wikipedia.org/wiki/United_States>
> federal law implementing Standard time
> <https://en.wikipedia.org/wiki/Standard_time#North_America> and
> Daylight saving time in the United States <https://en.wikipedia.org/wiki/Daylight_saving_time_in_the_United_States>.^[2]
> <https://en.wikipedia.org/wiki/Standard_Time_Act#cite_note-2> It
> defined five time zones for the United States and authorized the
> Interstate Commerce Commission
> <https://en.wikipedia.org/wiki/Interstate_Commerce_Commission> to
> define the limits of each time zone.
> 
> The section concerning daylight saving time was repealed by the act
> titled /An Act For the repeal of the daylight-saving law/, Pub. L.
> <https://en.wikipedia.org/wiki/Public_Law_(United_States)>Tooltip
> Public Law (United States) 66–40
> <https://uslaw.link/citation/us-law/public/66/40>, 41 Stat.
> <https://en.wikipedia.org/wiki/United_States_Statutes_at_Large> 280
> <https://legislink.org/us/stat-41-280>, enacted August 20, 1919, over
> President Woodrow Wilson
> <https://en.wikipedia.org/wiki/Woodrow_Wilson>'s veto.
> 
> Section 264 of the act mistakenly placed most of the state of Idaho
> <https://en.wikipedia.org/wiki/Idaho> (south of the Salmon River
> <https://en.wikipedia.org/wiki/Salmon_River_(Idaho)>) in UTC−06:00
> <https://en.wikipedia.org/wiki/UTC%E2%88%9206:00> CST (Central
> Standard Time <https://en.wikipedia.org/wiki/Central_Standard_Time>),
> but was amended in 2007 by Congress to UTC−07:00
> <https://en.wikipedia.org/wiki/UTC%E2%88%9207:00> MST (Mountain
> Standard Time
> <https://en.wikipedia.org/wiki/Mountain_Standard_Time>).^[3]
> <https://en.wikipedia.org/wiki/Standard_Time_Act#cite_note-google-3>
> MST was observed prior to the correction.

That's the idea—you have to go back to sources, and as you find them,
you check whether they actually took effect (newspaper archives being
a useful source here), and then you make "fixes and enhancements" to
the database, just as you quoted earlier.

As for the choice of "New York", perhaps easiest to quote the Wiki page:

 “Location is the name of a specific location within the area –
  usually a city or small island.

 “Country names are not normally used in this scheme, primarily
  because they would not be robust, owing to frequent political and
  boundary changes. The names of large cities tend to be more
  permanent. Usually the most populous city in a region is chosen
  to represent the entire time zone, although another city may be
  selected if it is more widely known, and another location, including
  a location other than a city, may be used if it results in a less
  ambiguous name. In the event that the name of the location used
  to represent the time zone changes, the convention is to create an
  alias in future editions so that both the old and new names
  refer to the same database entry.

 “In some cases the Location is itself represented as a compound name,
  for example the time zone "America/Indiana/Indianapolis". Three-level
  names include those under "America/Argentina/...",
  "America/Kentucky/...", "America/Indiana/...", and
  "America/North_Dakota/...".

 “The location selected is representative for the entire
  area. However, if there were differences within the area before 1970,
  the time zone rules only apply in the named location.”

Earlier, you wrote: "BTW there isn't any timezone called
America/New_York, it is or course the Eastern Standard Time Zone."

America/New_York is the name of a set of rules in the timezone
database, and we're discussing the relative merits of different sets
of rules, not the merits of the names.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →

csiph-web

ntpsec as server questions

Contents

#264301

#264302

#264317

#264340

#264343

#264344

#264345

#264346

#264347

#264348

#264350

#264353

#264362

#264365

#264366

#264367

#264369

#264370

#264372

#264376