Re: [OFFTOPIC] Filling the FAT (was: playing CDROM music questions)

[tomas]

On Tue, Jan 09, 2024 at 10:57:29AM -0500, Stefan Monnier wrote:
> >>What are you talking about? FAT does not get “overloaded” by long
> >>filenames.
> > Seen it happen;
> 
> I have serious doubts about the "it".
> 
> > Long filenames, mixed case, and files saved at the beginning of
> > a session of copying multiple files would be lost because the FAT was
> > filled, and overwritten from the start by files added later in
> > the session.
> 
> The FAT doesn't contain file names.  It has a fixed size and contains
> one "word" per block in the partition, and that word indicates simply if
> the corresponding block is free or not, and if not, what is the next
> block of the corresponding "file" (where that "file" may be also
> something like a directory).
> 
> The FAT doesn't get filled/emptied: it has the same size whether the
> partition is empty or full, because the partition contains a fixed
> number of blocks.
> 
> So, I don't doubt you have seen what you have seen, but whatever you
> have seen was not due to "the FAT was filled".

I gues we are talking about VFAT, otherwise the "long" filename doesn't
make much sense.

The LFS layer on top of FAT does have some limitations: "Because the
FAT LFN implementation is layered atop an older, more limited naming
system, there are inevitable complications, such as if an attempt is
made to create too many files with the same first six letters" [1].

Given the baroque construction of that thing (only Microsoft could've
come up with such a monster), I'd not be surprised if there were known
bugs kept around for backward compatibility.

So perhaps what Brad observed was a name collision in the underlying
("bare") FAT file system (I've seen that back then, Windows 3.1) or
some other strange inhabitant of that code biotope.

Cheers

[1] https://en.wikipedia.org/wiki/Long_filename
-- 
t


signature.asc
Description: PGP signature

Re: [OFFTOPIC] Filling the FAT (was: playing CDROM music questions)

[Brad Rogers]

On Tue, 9 Jan 2024 10:07:26 -0600
David Wright  wrote:

Hello David,

>The size of that is fixed when formatted, at least up to FAT16.
>Long filenames will eat it up more quickly still. Create
>subdirectories and the problem goes away.

Yes, this is exactly what I experienced.  So not the FAT at fault, but
rather the 'ecosystem'.

How time plays trick on one's memory.   :-(

-- 
 Regards  _   "Valid sig separator is {dash}{dash}{space}"
 / )  "The blindingly obvious is never immediately apparent"
/ _)rad   "Is it only me that has a working delete key?"
If you ain't sticking your knives in me, you will be eventually
Monsoon - Robbie Williams


pgp_96fXkiXqi.pgp
Description: OpenPGP digital signature

Re: [OFFTOPIC] Filling the FAT (was: playing CDROM music questions)

[David Wright]

On Tue 09 Jan 2024 at 10:57:29 (-0500), Stefan Monnier wrote:
> >>What are you talking about? FAT does not get “overloaded” by long
> >>filenames.
> > Seen it happen;
> 
> I have serious doubts about the "it".
> 
> > Long filenames, mixed case, and files saved at the beginning of
> > a session of copying multiple files would be lost because the FAT was
> > filled, and overwritten from the start by files added later in
> > the session.
> 
> The FAT doesn't contain file names.  It has a fixed size and contains
> one "word" per block in the partition, and that word indicates simply if
> the corresponding block is free or not, and if not, what is the next
> block of the corresponding "file" (where that "file" may be also
> something like a directory).
> 
> The FAT doesn't get filled/emptied: it has the same size whether the
> partition is empty or full, because the partition contains a fixed
> number of blocks.
> 
> So, I don't doubt you have seen what you have seen, but whatever you
> have seen was not due to "the FAT was filled".

I would agree with that. I don't follow the evolution of FAT,
but what seems most likely is that the root directory filled up.
The size of that is fixed when formatted, at least up to FAT16.
Long filenames will eat it up more quickly still. Create
subdirectories and the problem goes away.

With large sticks nowadays, the problem revolves more around the
/time/ it takes to read huge subdirectories. I don't know what
the limitations on FAT32 root directory sizes are.

Cheers,
David.

Re: [OFFTOPIC] Filling the FAT (was: playing CDROM music questions)

[Stefan Monnier]

>>What are you talking about? FAT does not get “overloaded” by long
>>filenames.
> Seen it happen;

I have serious doubts about the "it".

> Long filenames, mixed case, and files saved at the beginning of
> a session of copying multiple files would be lost because the FAT was
> filled, and overwritten from the start by files added later in
> the session.

The FAT doesn't contain file names.  It has a fixed size and contains
one "word" per block in the partition, and that word indicates simply if
the corresponding block is free or not, and if not, what is the next
block of the corresponding "file" (where that "file" may be also
something like a directory).

The FAT doesn't get filled/emptied: it has the same size whether the
partition is empty or full, because the partition contains a fixed
number of blocks.

So, I don't doubt you have seen what you have seen, but whatever you
have seen was not due to "the FAT was filled".


Stefan

Re: playing CDROM music questions

[Brad Rogers]

On Tue, 9 Jan 2024 16:15:27 +0100
Nicolas George  wrote:

Hello Nicolas,

>Pictures or it did not happen.

Didn't bother because it appeared to be a well-understood phenomenon,
based on my limited research.

-- 
 Regards  _   "Valid sig separator is {dash}{dash}{space}"
 / )  "The blindingly obvious is never immediately apparent"
/ _)rad   "Is it only me that has a working delete key?"
I'm not here for your entertainment
U & Ur Hand - P!nk


pgphyuPBCFJB5.pgp
Description: OpenPGP digital signature

Re: playing CDROM music questions

[Nicolas George]

Brad Rogers (12024-01-09):
> Seen it happen;  Long filenames, mixed case, and files saved at the
> beginning of a session of copying multiple files would be lost because
> the FAT was filled, and overwritten from the start by files added later
> in the session.
> 
> We are talking in excess of 20,000 (not difficult to achieve with
> over 1000 CDs to rip) files here, mixed case, and long file names, all.

Pictures or it did not happen.

-- 
  Nicolas George


signature.asc
Description: PGP signature

Re: playing CDROM music questions

[Brad Rogers]

On Tue, 9 Jan 2024 13:25:52 +0100
Nicolas George  wrote:

Hello Nicolas,

>What are you talking about? FAT does not get “overloaded” by long
>filenames.

Seen it happen;  Long filenames, mixed case, and files saved at the
beginning of a session of copying multiple files would be lost because
the FAT was filled, and overwritten from the start by files added later
in the session.

We are talking in excess of 20,000 (not difficult to achieve with
over 1000 CDs to rip) files here, mixed case, and long file names, all.

-- 
 Regards  _   "Valid sig separator is {dash}{dash}{space}"
 / )  "The blindingly obvious is never immediately apparent"
/ _)rad   "Is it only me that has a working delete key?"
It's only bits of plastic, lines projected on the wall
Keep It Clean - The Vibrators


pgpY9oz8w1d5M.pgp
Description: OpenPGP digital signature

Re: playing CDROM music questions

[Nicolas George]

Brad Rogers (12024-01-09):
> Depends;  I ended up buying three smaller sticks, because the
> limitations of the file system meant that the File Allocation Table
> got filled up wy before the larger capacity memory sticks did.

The USB sticks we were discussing in this thread are way below the
limitations of FAT.

> Even with the smaller sticks, I had to use all upper case, and stick to
> 8.3 names for the files, otherwise the FAT still got overloaded.

What are you talking about? FAT does not get “overloaded” by long
filenames.

-- 
  Nicolas George


signature.asc
Description: PGP signature

Re: playing CDROM music questions

[Nicolas George]

Haines Brown (12024-01-08):
> and that seems to  have fixed the buffer problem.

Nice.

> The scripts folder is in my path. I holds many commands I regularly 
> use.
> 
> Turns out that the "play" command was earlier taken by another 
> application. So I changed the command from play to Play, and now it 
> works without the cache problem. The Play command is:

I personally choose to have both a scripts directory not in my $PATH,
where I call the commands with explicit path, and a ~/bin directory at
the beginning of my path.

>   mplayer /dev/sr0 cdda://
> 
> The option -cdrom-device is default and so is optional. Mplayer works 
> fine without it. 

The option “-cdrom-device” cannot be the default because it is not
self-contained. It is possible “-cdrom-device /dev/sr0” is the default
on your system. But if you give the argument to the option without the
option, then I think that if you read mplayer's output more carefull you
will find it tried to play it as a file, failed and skipped it.

> where can find an inexpensive drive to hold about 1000 cds and find 

As was pointed out, we are looking at between 60 giga-octets
lossy-but-transparent and 500 giga-octets lossless, so between a
mid-sized USB stick and a small external hard drive.

Whether you consider it inexpensive is your estimate.

> the time do all the converting? ㋡ 

Eh, this one is obvious: while you listen to them.

You are writing a script to play your CD: just make the script a little
more powerful and it will rip them at the same time.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature

Re: playing CDROM music questions

[Brad Rogers]

On Mon, 8 Jan 2024 21:09:54 +
Michael Kjörling <2695bd53d...@ewoof.net> wrote:

Hello Michael,

>Alternatively, they also offer SanDisk SDXC 128 GB memory cards at $14
>a piece. One such will easily hold 1000 CDs at near-CD quality MP3.

Depends;  I ended up buying three smaller sticks, because the
limitations of the file system meant that the File Allocation Table
got filled up wy before the larger capacity memory sticks did.  I
would point out that, since the sticks were bought for use in my car,
reformatting to ext4 (for example) was not an option.

Even with the smaller sticks, I had to use all upper case, and stick to
8.3 names for the files, otherwise the FAT still got overloaded.

Of course, if you're going to reformat the sticks then the foregoing
issues are moot.

-- 
 Regards  _   "Valid sig separator is {dash}{dash}{space}"
 / )  "The blindingly obvious is never immediately apparent"
/ _)rad   "Is it only me that has a working delete key?"
I want those who get to know me to become admirers or my enemies
Friend or Foe - Adam Ant


pgpNCaahBYzGq.pgp
Description: OpenPGP digital signature

Re: playing CDROM music questions

[Roy J. Tellason, Sr.]

On Monday 08 January 2024 03:49:17 pm Haines Brown wrote:
> where can find an inexpensive drive to hold about 1000 cds and find 
> the time do all the converting? ㋡ 
 
The 4TB drive in my server has about 77GB roughly holding a similar amount of 
stuff.  The time was over a rather lengthy period of time,  not all done at 
once.


-- 
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James 
M Dakin

Re: playing CDROM music questions

[Stefan Monnier]

> The time to physically go through all those CDs, now that's a slightly
> different issue.

Once you've setup your "rip" tool (I used mostly `grip` back then,
not sure what's still maintained, maybe `abcde`?), it's a small matter
of putting the next CD in the drive when the previous one is ejected
(i.e. every 10 minutes or so).
I did it while doing other things on my computer.

The hardest part is labeling the resulting audio files: while some CDs
have good data in CDDB and friends (so the rip tool can do a good job
auto-labeling), not all do, sadly.


Stefan

Re: playing CDROM music questions

[Michael Kjörling]

On 8 Jan 2024 15:49 -0500, from hai...@histomat.net (Haines Brown):
>> But unless you cannot spare 60 megaoctets somewhere, save yourself a lot
>> of trouble: just run cdparanoia -B then opusenc and put back the audio
>> CD at the back of the shelf where it belongs.
> 
> where can find an inexpensive drive to hold about 1000 cds and find 
> the time do all the converting? ㋡ 

I don't know what you consider inexpensive, but even uncompressed,
1000 CDs is about 700-800 GB. (FLAC will approximately halve that; MP3
at close to CD quality will reduce it to about 1/10.) Just a quick
check, Amazon lists a USB3 1TB Seagate HDD for $58 plus shipping,
though I've heard some horror stories about buying storage media from
Amazon as of late. There are certainly other options available, both
in terms of hardware, suppliers and resellers. Also 1 TB is
sufficiently small that the next step up isn't appreciably more
expensive; a similar 2 TB model lists for $70, for example.

Alternatively, they also offer SanDisk SDXC 128 GB memory cards at $14
a piece. One such will easily hold 1000 CDs at near-CD quality MP3.

The time to physically go through all those CDs, now that's a slightly
different issue.

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Re: playing CDROM music questions

[Haines Brown]

On Mon, Jan 08, 2024 at 05:37:00PM +0100, Michel Verdier wrote:
> On 2024-01-08, Haines Brown wrote:

> > But the $ play command only returns the aplay -help info. Why won't 
> > the script work?
> 
> You fumble on another "play" program. Try "type -a play" to
> confirm. Then just rename your script.

You are correct. Renaming the file did the trick.
 
-- 

 Haines Brown 

Re: playing CDROM music questions

[Haines Brown]

On Mon, Jan 08, 2024 at 04:32:37PM +, Michael Kjörling wrote:

> I suspect this is because of insufficient read-ahead or insufficient
> bandwidth, as you seems to assume to based on your comment on buffer
> size. You might be able to use --cache=yes to improve matters.

To judge by the man mplayer, I suspect the line in the config file 
would be cache = enable

Although all the cache lines in /etc/mplayer/mplayer.conf are 
commented out, simply replacing the line # cache = 8192 with the line 
cache = 16384 solved the buffer problem. Is cache thereby enabled? 

> Check the output of: type play
> 
> Most likely something else named play comes earlier in your $PATH.

You are correct. Solved the problem by changing play to Play.

Thank you.
 

> Michael Kjörling  https://michael.kjorling.se
> “Remember when, on the Internet, nobody cared that you were a dog?”


-- 

 Haines Brown 

Re: playing CDROM music questions

[Haines Brown]

On Mon, Jan 08, 2024 at 05:23:34PM +0100, Nicolas George wrote:
> Haines Brown (12024-01-08):
> > I find that often (such as wiki.debian.org/CDDVD) I'm told to mount 

Understood about not mounting CDROM disks. Confused music with data 
disks

> > The mplayer command $ mplayer -cdrom-device /dev/sr0 cdda:// works. On 
> > my system it relies on alsa. However, about every 15 seconds the the 
> > process stops for about one second ane the drive LED flashes on. In 
> > the mplayer configuration I do D not see anything about buffer size.
> 
> Search for “cache” in the man page.

Thanks! That solved my problem. I find cache (enable/disable) and 
cache size (cache). 

In /etc/mplayer/mplayer.conf there is a cache section. I changed the 
line

# cache = 8192
 
  to 

cache = 16384

and that seems to  have fixed the buffer problem.
 
> > To simplify my life, I created a ~/scripts/play file. It is in my 
> > PATH. The file has this content:
> > 
> >   #!/bin/sh
> > 
> >   mplayer /dev/sr0 cdda://
> > 
> >   exit 0
> > 
> > But the $ play command only returns the aplay -help info. Why won't 
> > the script work?
> 
> You forgot the “-cdrom-device” option. And judging from what you are
> saying you need to learn how $PATH works.

The scripts folder is in my path. I holds many commands I regularly 
use.

Turns out that the "play" command was earlier taken by another 
application. So I changed the command from play to Play, and now it 
works without the cache problem. The Play command is:

mplayer /dev/sr0 cdda://

The option -cdrom-device is default and so is optional. Mplayer works 
fine without it. 

> But unless you cannot spare 60 megaoctets somewhere, save yourself a lot
> of trouble: just run cdparanoia -B then opusenc and put back the audio
> CD at the back of the shelf where it belongs.

where can find an inexpensive drive to hold about 1000 cds and find 
the time do all the converting? ㋡ 

> 
> Regards,
> 
> -- 
>   Nicolas George
> 

-- 

 Haines Brown 

CD-DA sector addressing, was Re: playing CDROM music questions

[Thomas Schmitt]

Hi,

i cannot contribute much to the practical issues with playing music.
But i'd like to clarify technical properties of CD-DA media:

Nicolas George wrote:
> compared to data CDs, audio CDs lack one layer of error-correcting code

True.

Another drawback is that CD-DA sectors cannot be read by the usual SCSI
commands for hard disk reading, but only by the special command READ CD.

> and [lack] the synchronization necessary to tell the
> position of a particular sector.

Not true. It is possible to read CD-DA with sector granularity.

Random addressing may be somewhat cumbersome for the drive, because the
exact sector address is part of the low level data of the sector.
See MMC-5 4.2.3.5.2 "Mode-1 Q" for how it is implemented on medium and
6.20 "READ CD Command" for how it is to be operated by software of the
hosting computer.

> This is why tools like cdparanoia exist: between one read and the next
> they seek back a few sectors and check that the overlap matches.

If ever it is the drive's firmware which has to guess the position and
then to pick the sectors with the desired address in Mode-1 Q (or in a
neighbor if one of the 10% sectors without Mode-1 Q is desired).

The main reason for specialized CD readers like cdparanoia is rather in
the fact that data readers like mount(8) want to use the general SCSI disk
read commands. There are more reasons, as the man page of cdparanoia
indicates, including workarounds for bugs of antique drives.


Have a nice day :)

Thomas

Re: playing CDROM music questions

[Nicolas George]

Michael Kjörling (12024-01-08):
> Note that while CD-DA disks are technically CD-ROM disks (compact disk
> read only media), in typical usage "CD-ROM" is taken to mean a CD
> which contains _data organized as files within a file system_, often
> an ISO-9660 file system typically with extensions (Rockridge, Juliet,
> ...).

It is worse than that: compared to data CDs, audio CDs lack one layer of
error-correcting code and the synchronization necessary to tell the
position of a particular sector.

This is why tools like cdparanoia exist: between one read and the next
they seek back a few sectors and check that the overlap matches.

But on the other hand, an audio CD can contain up to 807 mega-octets of
audio, compared to only 703 for a data CD.

Regards,

-- 
  Nicolas George

Re: playing CDROM music questions

[Michel Verdier]

On 2024-01-08, Haines Brown wrote:

> I find that often (such as wiki.debian.org/CDDVD) I'm told to mount 
> the cdrive. But I can play cds without mounting. Wny is mounting 
> sometimes recommended?

It talks about mounting "data" CD. Audio CD cannot be mounted and are
accessed by device (like /dev/sr0).

> But the $ play command only returns the aplay -help info. Why won't 
> the script work?

You fumble on another "play" program. Try "type -a play" to
confirm. Then just rename your script.

Re: playing CDROM music questions

[Michael Kjörling]

On 8 Jan 2024 11:00 -0500, from hai...@histomat.net (Haines Brown):
> I find that often (such as wiki.debian.org/CDDVD) I'm told to mount 
> the cdrive. But I can play cds without mounting. Wny is mounting 
> sometimes recommended?

You mount a file system. Audio CDs (that is, CD-DA disks) do not hold
file systems, so they aren't mounted in the typical sense.

Note that while CD-DA disks are technically CD-ROM disks (compact disk
read only media), in typical usage "CD-ROM" is taken to mean a CD
which contains _data organized as files within a file system_, often
an ISO-9660 file system typically with extensions (Rockridge, Juliet,
...).


> I wanted to use aplay to play music on cdrom, but have concluded
> it cannot be done in any straightforward way. Why not?

Likely simply because nobody has implemented that. Software to play
audio CDs exists aplenty; is there any particular reason why you want
to use specifically aplay to do it?


> However, about every 15 seconds the the
> process stops for about one second ane the drive LED flashes on.

I suspect this is because of insufficient read-ahead or insufficient
bandwidth, as you seems to assume to based on your comment on buffer
size. You might be able to use --cache=yes to improve matters.

Another option is to copy the CD audio to the computer using some tool
designed for that, and then play the copy. I suggest trying cdparanoia
for this, as it has excellent handling of poor read quality or buffer
underrun/overrun.


> To simplify my life, I created a ~/scripts/play file. It is in my 
> PATH. The file has this content:
> 
>   #!/bin/sh
> 
>   mplayer /dev/sr0 cdda://
> 
>   exit 0
> 
> But the $ play command only returns the aplay -help info. Why won't 
> the script work?

Check the output of: type play

Most likely something else named play comes earlier in your $PATH.

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Re: playing CDROM music questions

[Nicolas George]

Haines Brown (12024-01-08):
> I find that often (such as wiki.debian.org/CDDVD) I'm told to mount 

Please do not remove the protocol part from the URL, it makes
auto-detection and copy-pasting more annoying.

> the cdrive.

I do not see this page suggesting to mount audio CDs. Audio CDs do not
contain a files system, nor do they contain the synchronization
information necessary for a reliable read.

There is a hack in the kernel to mount them and present audio track as
PCM files but it is a hack, I do not know if it is enabled by default
and I do not recommend too use it.

> But I can play cds without mounting. Wny is mounting 
> sometimes recommended?

Either people are wrong to recommend it or you are mistaken in thinking
they recommend it.

> I wanted to use aplay to play music on cdrom, but have concluded 
> it cannot be done in any straightforward way. Why not?

Because aplay requires the data to be available as a plain stream of
octets and the kernel does not provide that interface for audio CDs.

> The mplayer command $ mplayer -cdrom-device /dev/sr0 cdda:// works. On 
> my system it relies on alsa. However, about every 15 seconds the the 
> process stops for about one second ane the drive LED flashes on. In 
> the mplayer configuration I do D not see anything about buffer size.

Search for “cache” in the man page.

> To simplify my life, I created a ~/scripts/play file. It is in my 
> PATH. The file has this content:
> 
>   #!/bin/sh
> 
>   mplayer /dev/sr0 cdda://
> 
>   exit 0
> 
> But the $ play command only returns the aplay -help info. Why won't 
> the script work?

You forgot the “-cdrom-device” option. And judging from what you are
saying you need to learn how $PATH works.

But unless you cannot spare 60 megaoctets somewhere, save yourself a lot
of trouble: just run cdparanoia -B then opusenc and put back the audio
CD at the back of the shelf where it belongs.

Regards,

-- 
  Nicolas George

playing CDROM music questions

[Haines Brown]

I wish to play cdrom music discs from an exterrnal USB CDROM drive. It 
is the Rioddas drive recomended for linux.

I find that often (such as wiki.debian.org/CDDVD) I'm told to mount 
the cdrive. But I can play cds without mounting. Wny is mounting 
sometimes recommended?

I wanted to use aplay to play music on cdrom, but have concluded 
it cannot be done in any straightforward way. Why not?

The mplayer command $ mplayer -cdrom-device /dev/sr0 cdda:// works. On 
my system it relies on alsa. However, about every 15 seconds the the 
process stops for about one second ane the drive LED flashes on. In 
the mplayer configuration I do D not see anything about buffer size.

To simplify my life, I created a ~/scripts/play file. It is in my 
PATH. The file has this content:

  #!/bin/sh

  mplayer /dev/sr0 cdda://

  exit 0

But the $ play command only returns the aplay -help info. Why won't 
the script work?

-- 

 Haines Brown 

Re: ntpsec as server questions

[Max Nikulin]

On 05/12/2023 01:41, Greg Wooledge wrote:

unicorn:~$ LC_TIME=en_US.utf8 printf '%(%c)T\n'
Mon 04 Dec 2023 01:34:42 PM EST

Sadly, you're restricted to the choices offered by your installed locales.
If you can't find an installed locale which has an acceptable LC_TIME
format, then you can try to roll your own.  I went down that road once.
It didn't really work out for me.  Too many finicky details that simply
don't work out in reality.


I think, absence of really flexible time formats may be intentional. At 
first I was surprised that Intl.DateTimeFormat in JavaScript does not 
have a method similar to strftime.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat/DateTimeFormat
Perhaps I have noticed rationale reading docs related to the Temporal 
proposal. Time formats vary greatly across the world. So if a developer 
fix particular format using % specifiers then the format may be rather 
strange for users from other countries. It is safer to specify locale 
and some hints like long/short. In addition, Gregorian calendar is not 
the only option.


Formats of dates and time are a part of Common Locale Data Repository
https://cldr.unicode.org/

Re: Local time in databases (Re: ntpsec as server questions)

[Max Nikulin]

On 08/12/2023 11:38, to...@tuxteam.de wrote:

On Thu, Dec 07, 2023 at 10:18:44PM -0600, Nicholas Geovanis wrote:


All of these considerations are what brought Oracle to create a proprietary
"datetime" datatype and use it to store all "real" dates/times. If you need
a different format for display purposes or a human readable column, you can
extract it and do that. But the internal  representation will be driven by
other needs.


If anyone is looking for inspiration, I think what PostgreSQL does is one of
the best and most complete implementations I've seen.


I know nothing concerning the datetime type in Oracle.

Postgres stores timestamps as a numbers. Its power is reliable 
conversion to client time zone (or between time zones). "timestamp with 
time zone" is actually duration since epoch (UTC) and conversion to a 
time zone on select.


However storing local time might be tricky. A week may have 2 Fridays 
with the same date.


zdump -v America/Juneau

America/Juneau  Sat Oct 19 00:31:12 1867 UT
 = Sat Oct 19 15:33:31 1867 LMT isdst=0 gmtoff=54139
America/Juneau  Sat Oct 19 00:31:13 1867 UT
 = Fri Oct 18 15:33:32 1867 LMT isdst=0 gmtoff=-32261

Some territories crossed the international date line.

Re: ntpsec as server questions

[Max Nikulin]

On 08/12/2023 23:12, Bonno Bloksma wrote:

So, in pseudo code
   bool isleapyear (int year) {
   return false;


I've heard such a calendar was in use in ancient Egypt.
https://en.wikipedia.org/wiki/Sothic_cycle
Its disadvantage was that crop reaping and tax paying dates were slowly 
becoming out of sync. However every 1461 years it was returning to 
originally established order.

ntpsec as server questions

[gene heskett]

I had a total crash and among the things missing after the psu was 
replaced, was apparently all my tbird message tags, as I had been 
tagging this whole thread so I could look it up again after the dust 
settled. But now I have no tags.


ISTR someone gave me a journalctl line that picked out all the ntp 
stuff, including all the traffic because before the crash I was not only 
serving the printer I gad managed to collect 10-15 other clients nut 
after the rework and 30+ reboots I cannot find that message again, and I 
need it.


Can I trouble whoever posted it to repeat it, please?

Thank you.

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

Re: ntpsec as server questions

[David Wright]

On Thu 07 Dec 2023 at 22:07:44 (-0500), Greg Wooledge wrote:
> On Fri, Dec 08, 2023 at 09:38:43AM +0700, Max Nikulin wrote:
> > - IANA TZ DB does not support timezones disappeared before 1970.
> >   
> 
> Ohhh, *this* is the kind of reference I've been looking for.
> 
> So, we simply acknowledge that historical clock information prior to 1970
> is just not feasibly discoverable.  All of the time zone choices are
> going to be flawed, for almost all of the people in the world.  We just
> pick from the ones that are known to be good enough.

Where it's felt important enough, or is accessible enough,
people are prepared, it seems, to do the necessary work.
Britain appears to lead the world in that respect. It
probably helps to be a small, civilized country. :)

  https://www.polyomino.org.uk/british-time/

On the subject of leap seconds, I think there's a point
that's missed on this Wiki page:
https://en.wikipedia.org/wiki/Greenwich_Time_Signal
where it says: "Until 1972, the pips were of equal length
and confusion arose as to which was the final pip, hence
the last pip is now of extended length."

My recollection is of listening to the first "leap pip"
on Radio4, which was the first time the final pip had
been made longer. (There had been discussions about
leap seconds on Radio4 in the lead up to the event.)

Cheers,
David.

Re: ntpsec as server questions

[Greg Wooledge]

On Fri, Dec 08, 2023 at 04:12:54PM +, Bonno Bloksma wrote:
> Hi Greg,
> > bool isleapyear (int year) {
> > if (year % 400 == 0) return true;
> > if (year % 100 == 0) return false;
> > if (year % 4 == 0) return true;
> > return false;
> > }
> 
> Except, I think it should be in reverse order because now 2000 first gets a 
> true, then a false but then a true again and after that EVERYTHING gets a 
> false ;-)

No, because "return" is immediate.  It's not "set the return value to this,
and then that'll be the thing the function returns when you reach the end".
It's "return this value RIGHT NOW and don't go any farther".

> So, in pseudo code
>   bool isleapyear (int year) {
>   return false;
>   if (year % 4 == 0) return true;
>   if (year % 100 == 0) return false;
>   if (year % 400 == 0) return true;
>   }

Your way should be:

bool isleapyear (int year) {
bool ret = false;
if (year % 4 == 0) ret = true;
if (year % 100 == 0) ret = false;
if (year % 400 == 0) ret = true;
return ret;
}

Your way does three modulus operations every time, no matter what.  Mine
will do fewer than 3 if it gets lucky (input is a multiple of 100).

RE: ntpsec as server questions

[Bonno Bloksma]

Hi Greg,

>  The rule for leap years is:
>
>   Every year that is exactly divisible by four is a leap year, except
>   for years that are exactly divisible by 100, but these centurial years
>   are leap years if they are exactly divisible by 400. For example, the
>   years 1700, 1800, and 1900 are not leap years, but the year 2000 is.

> I don't have my copy of K close to hand, but my preferred implementation 
> for a function that decides leap years is (pseudo-code):
> 
> bool isleapyear (int year) {
> if (year % 400 == 0) return true;
> if (year % 100 == 0) return false;
> if (year % 4 == 0) return true;
> return false;
> }

Except, I think it should be in reverse order because now 2000 first gets a 
true, then a false but then a true again and after that EVERYTHING gets a false 
;-)
So, in pseudo code
  bool isleapyear (int year) {
  return false;
  if (year % 4 == 0) return true;
  if (year % 100 == 0) return false;
  if (year % 400 == 0) return true;
  }

The funny thing is, a lot of people I taught programming in the 80's and 90's 
knew about the 4 year rule but not the exceptions. But programming it like that 
would work for however long that program would be around anyway. 
I know all of the programs I wrote commercially have been superseded by 
something else now, so it did not matter that I did it correctly. ;-)

Bonno Bloksma

Re: ntpsec as server questions

[Thomas Schmitt]

Hi,

gene heskett wrote:
> > In the FWIW dept this time formula is pretty accurate back to the
> > middle of 4713 BC.

Greg Wooledge wrote:
> Even the *Julian* calendar used in ancient Rome wouldn't have been in
> use in 4713 BC.  Any calendar would have been locally defined, if one
> existed at all.

What Gene describes is the Julian Date, an astronomical time counting.
I first met it in HP BASIC but it is also used by database systems.
0.00 is 1st Januar 4713 BC 12:00 UTC (year -4712 because the is
no year 0 in BC/AD counting).

It must not be confused with the Julian Calendar, which invented the
the 4-year leap year rule.
This worked until pope Gregor saw the need for a finer adjustment to the
day fractions of the astronomical year. This yielded the rules about
100 and 400 years.

Afaik, they all suffer from being day-oriented which makes trouble because
the astronomical days get longer over time and thus cause leap seconds.
For long term accuracy in the range of seconds one needs to work with time
countings close to International Atomic Time (TAI) which is nearly perfect
but becomes only available up to a month too late.


Have a nice day :)

Thomas

Re: ntpsec as server questions

[tomas]

On Fri, Dec 08, 2023 at 07:32:25AM -0500, Greg Wooledge wrote:

[...]

> Also, the idea that a calculation of *anything* in our current Gregorian
> calendar system would extend back to a BC date is ludicrous [...]

The high-class version of this swear word would be "proleptic". But yeah,
I agree with you :-)

For all the mess involved, and how the calendar change moved through the
so-called civilised world, or not, see [1]. Revolts and all (because folks
tended to believe they had been stolen days of their lives).

Now look at a birth date recorded back then in some small-village parish
by a priest "under spirits" and guess what the real Unix time was back
then ;^)

Cheers

[1] https://en.wikipedia.org/wiki/Adoption_of_the_Gregorian_calendar
-- 
t


signature.asc
Description: PGP signature

Re: ntpsec as server questions

[Greg Wooledge]

On Thu, Dec 07, 2023 at 11:19:19PM -0500, gene heskett wrote:
> [...] a method for determining leap years. It was also
> used in some astronomical programs for lunar and solar eclipses. This I
> think was the reason that all unix times start at midnight 1/1/1970. In the
> FWIW dept this time formula is pretty accurate back to the middle of 4713
> BC.

You're not actually talking about leap years, are you?  Are you maybe
talking about *Easter*?  Or something involving the spring equinox?

Also, the idea that a calculation of *anything* in our current Gregorian
calendar system would extend back to a BC date is ludicrous, as the
Gregorian calendar was not in use at that time.  It wasn't invented
until thousands of years later.

Even the *Julian* calendar used in ancient Rome wouldn't have been in
use in 4713 BC.  Any calendar would have been locally defined, if one
existed at all.

Re: ntpsec as server questions

[Greg Wooledge]

On Thu, Dec 07, 2023 at 11:19:19PM -0500, gene heskett wrote:
> Of minor interest to me, not once in the above link does it credit the K
> Manual for C, which has a method for determining leap years.

The what now?  Leap years are defined by the Gregorian Calendar, as
declared in the 16th century, long before K

https://en.wikipedia.org/wiki/Gregorian_calendar

  The rule for leap years is:

Every year that is exactly divisible by four is a leap year, except
for years that are exactly divisible by 100, but these centurial years
are leap years if they are exactly divisible by 400. For example, the
years 1700, 1800, and 1900 are not leap years, but the year 2000 is.

— United States Naval Observatory[2]

I don't have my copy of K close to hand, but my preferred implementation
for a function that decides leap years is (pseudo-code):

bool isleapyear (int year) {
if (year % 400 == 0) return true;
if (year % 100 == 0) return false;
if (year % 4 == 0) return true;
return false;
}

Why would you expect a time zone database to acknowledge one
implementation of a simple Gregorian leap year function?

Re: Local time in databases (Re: ntpsec as server questions)

[tomas]

On Thu, Dec 07, 2023 at 10:18:44PM -0600, Nicholas Geovanis wrote:

[...]

> All of these considerations are what brought Oracle to create a proprietary
> "datetime" datatype and use it to store all "real" dates/times. If you need
> a different format for display purposes or a human readable column, you can
> extract it and do that. But the internal  representation will be driven by
> other needs.
> YMMV :-)

If anyone is looking for inspiration, I think what PostgreSQL does is one of
the best and most complete implementations I've seen.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Local time in databases (Re: ntpsec as server questions)

[tomas]

On Fri, Dec 08, 2023 at 09:11:12AM +0700, Max Nikulin wrote:
> On 07/12/2023 23:08, tomas wrote:
> > On Thu, Dec 07, 2023 at 10:29:29PM +0700, Max Nikulin wrote:
> > > On 07/12/2023 21:22, John Hasler wrote:
> > > > Databases should never store local time.
> > > 
> > > There are exceptions when storing UTC instead of local time leads to
> > > undesired consequences.
> > 
> > Heh. There was one huge thread in Emacs user about a year ago (don't
> > ask me in which time zone).
> 
> Perhaps you mean emacs-ormode.

Right, that was it. I envy your memory :-)

> Then an important difference arises.
> Timestamp are stored not in a database, but in a plain text file and must be
> human readable, moreover some users prefer to type timestamps directly
> without dedicated commands.

The difference is there, but basically, it's minor.

> Leaving aside future timestamps that may need local time, significant
> fraction of timestamps may be reliably represented in UTC. I still have no
> clue why some people were strongly against local time with explicit time
> offset "2023-12-07 17:08:50 +0100". From my point of view such format may be
> unambiguously mapped to UTC "2023-12-07T16:08:50Z" and more convenient for
> users residing in Europe/Berlin. There were participants insisting on either
> forcing UTC or using IANA identifiers "2023-12-07 17:08:50 Europe/Berlin".
> The latter format has issues close to backward DST time shifts and should be
> augmented with disambiguation hints.

100% agreement. Perhaps *both* is best: the time zone (to keep "intention")
and the offset (to keep "actual time"). If I could go backwards in time
(heh ;-), that's what I would have talked that customer into.

[...]

> Local time is widely used in logs. The question is if the client can accept
> ambiguity

This was an industrial application logging measurements from machines all
over the place (and to different log files), so if a shed went up in flames,
you'd be comparing different logs to each other to try to find out what
went wrong.

So no, IMO not in that case. It took me days of talking :-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: ntpsec as server questions

[gene heskett]

On 12/7/23 22:08, Greg Wooledge wrote:

On Fri, Dec 08, 2023 at 09:38:43AM +0700, Max Nikulin wrote:

- IANA TZ DB does not support timezones disappeared before 1970.
   


Ohhh, *this* is the kind of reference I've been looking for.

So, we simply acknowledge that historical clock information prior to 1970
is just not feasibly discoverable.  All of the time zone choices are
going to be flawed, for almost all of the people in the world.  We just
pick from the ones that are known to be good enough.

.
Of minor interest to me, not once in the above link does it credit the 
K Manual for C, which has a method for determining leap years. It was 
also used in some astronomical programs for lunar and solar eclipses. 
This I think was the reason that all unix times start at midnight 
1/1/1970. In the FWIW dept this time formula is pretty accurate back to 
the middle of 4713 BC.


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

Re: Local time in databases (Re: ntpsec as server questions)

[Nicholas Geovanis]

On Thu, Dec 7, 2023, 8:11 PM Max Nikulin  wrote:

> On 07/12/2023 23:08, tomas wrote:
> > On Thu, Dec 07, 2023 at 10:29:29PM +0700, Max Nikulin wrote:
> >> On 07/12/2023 21:22, John Hasler wrote:
> >>> Databases should never store local time.
> >>
> >> There are exceptions when storing UTC instead of local time leads to
> >> undesired consequences.
> >
> > Heh. There was one huge thread in Emacs user about a year ago (don't
> > ask me in which time zone).
>
> Perhaps you mean emacs-ormode.
>


> Leaving aside future timestamps that may need local time, significant
> fraction of timestamps may be reliably represented in UTC.
>


> As I said above I see nothing wrong in local time with explicit time
> offset. Mail has been using it for decades:
> > Date: Thu, 7 Dec 2023 17:08:50 +0100
>

All of these considerations are what brought Oracle to create a proprietary
"datetime" datatype and use it to store all "real" dates/times. If you need
a different format for display purposes or a human readable column, you can
extract it and do that. But the internal  representation will be driven by
other needs.
YMMV :-)

Re: ntpsec as server questions

[Greg Wooledge]

On Fri, Dec 08, 2023 at 09:38:43AM +0700, Max Nikulin wrote:
> - IANA TZ DB does not support timezones disappeared before 1970.
>   

Ohhh, *this* is the kind of reference I've been looking for.

So, we simply acknowledge that historical clock information prior to 1970
is just not feasibly discoverable.  All of the time zone choices are
going to be flawed, for almost all of the people in the world.  We just
pick from the ones that are known to be good enough.

Re: ntpsec as server questions

[Max Nikulin]

On 07/12/2023 06:11, 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.


Which is why I prefer to use EST5DST


It may be a valid reason, however
- You stated that you do not care concerning historical timestamps.
- It is still unclear for me for what territory EST5EDT is more correct 
than America/New_York or another similar timezone. My expectation is 
that America/New_York is accurate at least for New York and 
America/Detroit is accurate for Detroit.

- EST5EDT in Debian is extension in respect to POSIX.
- America/New_York and EST2EDT are both provided by the same tzdata 
package, so quality of America/New_York is not worse.

- IANA TZ DB does not support timezones disappeared before 1970.
  
- After 1970 these timezones have no discrepancy.

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.


For me America/New_York is just an identifier. Perhaps you do not like 
this city for some reason, but for me it has no negative context. 
Decisions related to identifiers are clarified in



After all

ls -l /usr/share/zoneinfo/US/Eastern
lrwxrwxrwx 1 root root 19 May 29  2023 /usr/share/zoneinfo/US/Eastern -> 
../America/New_York


For most of users I still recommend to stick to names like America/New_York.

I would not neglect IANA TZ DB just because it has usual disclaimer. 
Despite POSIX is a standard, I see efforts to keep TZ DB accurate. That 
is why reputation of IANA, Arthur David Olson, and Paul Eggert has more 
value for me.

Re: Local time in databases (Re: ntpsec as server questions)

[Max Nikulin]

On 07/12/2023 23:08, tomas wrote:

On Thu, Dec 07, 2023 at 10:29:29PM +0700, Max Nikulin wrote:

On 07/12/2023 21:22, John Hasler wrote:

Databases should never store local time.


There are exceptions when storing UTC instead of local time leads to
undesired consequences.


Heh. There was one huge thread in Emacs user about a year ago (don't
ask me in which time zone).


Perhaps you mean emacs-ormode. Then an important difference arises. 
Timestamp are stored not in a database, but in a plain text file and 
must be human readable, moreover some users prefer to type timestamps 
directly without dedicated commands.


Leaving aside future timestamps that may need local time, significant 
fraction of timestamps may be reliably represented in UTC. I still have 
no clue why some people were strongly against local time with explicit 
time offset "2023-12-07 17:08:50 +0100". From my point of view such 
format may be unambiguously mapped to UTC "2023-12-07T16:08:50Z" and 
more convenient for users residing in Europe/Berlin. There were 
participants insisting on either forcing UTC or using IANA identifiers 
"2023-12-07 17:08:50 Europe/Berlin". The latter format has issues close 
to backward DST time shifts and should be augmented with disambiguation 
hints.



After having a long and fruitless discussion with a customer (they
insisted in having local time in a log file, which is almost always
the wrong thing) I came to the conclusion that in such situations
it's best to give them what they want -- but store time zone *and*
time offset with it.


Local time is widely used in logs. The question is if the client can 
accept ambiguity


LANG=C.UTF-8 TZ=Europe/Berlin date -d 'TZ="Z" 2023-10-29 00:30' '+%F %T'
2023-10-29 02:30:00
LANG=C.UTF-8 TZ=Europe/Berlin date -d 'TZ="Z" 2023-10-29 01:30' '+%F %T'
2023-10-29 02:30:00

That are

LANG=C.UTF-8 TZ=Europe/Berlin date -d 'TZ="Z" 2023-10-29 00:30' '+%F %T 
%z %Z'

2023-10-29 02:30:00 +0200 CEST
LANG=C.UTF-8 TZ=Europe/Berlin date -d 'TZ="Z" 2023-10-29 01:30' '+%F %T 
%z %Z'

2023-10-29 02:30:00 +0100 CET

Another case to consider it integration with 3rd party log analyzing 
tools and time formats that they can parse.


As I said above I see nothing wrong in local time with explicit time 
offset. Mail has been using it for decades:



Date: Thu, 7 Dec 2023 17:08:50 +0100

Re: Local time in databases (Re: ntpsec as server questions)

[tomas]

On Thu, Dec 07, 2023 at 10:29:29PM +0700, Max Nikulin wrote:
> On 07/12/2023 21:22, John Hasler wrote:
> > Databases should never store local time.
> 
> I am anticipating a new branch of hot discussion.
> 
> There are exceptions when storing UTC instead of local time leads to
> undesired consequences.

Heh. There was one huge thread in Emacs user about a year ago (don't
ask me in which time zone).

You are right. Sometimes local time is the right thing. Sometimes it's
the wrong thing. Context matters and so on.

After having a long and fruitless discussion with a customer (they
insisted in having local time in a log file, which is almost always
the wrong thing) I came to the conclusion that in such situations
it's best to give them what they want -- but store time zone *and*
time offset with it.

> Planned (future) events may be bound namely to local time. So if timezone
> offset rules are changed [...]

Yep, that's one of those. Even on a planned change -- regular planned
events are local time: show up at work at 10 o'clock means local time.

[...]

The intersection of technology and "human stuff" is often messy. Look
closely at Unicode to have yet another bunch of fun :-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: ntpsec as server questions

[David Wright]

On Thu 07 Dec 2023 at 09:37:29 (-0500), Pocket wrote:
> On 12/7/23 09:22, John Hasler wrote:
> > Greg writes:
> > > You'd think that you can determine the length of the test by
> > > subtracting the start time from the end time, right?
> > That would have worked had the times been stored as UTC (better yet, TAI
> > or Unix time since UTC can cause a similar problem).  Databases should
> > never store local time.
> 
> Yes that is true.
> 
> I use UTC on all my systems as I have some windows machines, one win
> xp dell laptop and two win 7 one laptop and one desktop.

That must be very confusing if you mean that, for example,
the bash prompt after you'd just sent that post said:

  hostname!pocket 14:38:29 ~$ 

Even if databases store UTC, they have to have front ends on local
time for data entry and reporting, unless you're going to have no
human involvement. And those original dates and times need to be
preserved or recreatable for auditing against any contemporary
records that are in local time. There may be several "local times"
in use in large organisations.

Cheers,
David.

Local time in databases (Re: ntpsec as server questions)

[Max Nikulin]

On 07/12/2023 21:22, John Hasler wrote:

Databases should never store local time.


I am anticipating a new branch of hot discussion.

There are exceptions when storing UTC instead of local time leads to 
undesired consequences.


Planned (future) events may be bound namely to local time. So if 
timezone offset rules are changed due to new administrative regulations 
then UTC timestamp becomes invalid. I do not mean regular spring and 
fall time transitions related to DST. It may be decided to cancel or to 
introduce DST, to shift dates when it is effective, to change time 
offset for some territory. 10:00am local time remains 10:00am despite 
before a new bill it is 15:00 UTC and it will be 14:00 UTC after. This 
is a case for various calendar applications.


Historical documents specify local time. Time zone database may contain 
incorrect data. Fixing TZ DB should not change local time for the stored 
event.


Additional data may be required when local time is stored: time zone 
identifier, disambiguation rule in the case of backward time transition 
close to the event time, location for the case that existing time zone 
will be split.


Despite calculation may be performed using UTC timestamps, local time is 
definitive in these cases.

Re: ntpsec as server questions

[Pocket]

On 12/7/23 09:22, John Hasler wrote:

Greg writes:

You'd think that you can determine the length of the test by
subtracting the start time from the end time, right?

That would have worked had the times been stored as UTC (better yet, TAI
or Unix time since UTC can cause a similar problem).  Databases should
never store local time.


Yes that is true.

I use UTC on all my systems as I have some windows machines, one win xp 
dell laptop and two win 7 one laptop and one desktop.


The dell seems to be too old to use bookworm and the others are used for 
apps that only run on windows (3d cad engineering)


I just purchased a new laptop yesterday (the price was too good to pass 
up)  so I guess I will find out the trials and tribulations of 
installing bookworm on a new machine with secure boot and the new boot 
systems.  I have only have experience with BIOS boot loaders.


Maybe there will be another thread for that ;)

--
It's not easy to be me

Re: ntpsec as server questions

[John Hasler]

Greg writes:
> You'd think that you can determine the length of the test by
> subtracting the start time from the end time, right?

That would have worked had the times been stored as UTC (better yet, TAI
or Unix time since UTC can cause a similar problem).  Databases should
never store local time.
-- 
John Hasler 
j...@sugarbit.com
Elmwood, WI USA

Re: ntpsec as server questions

[Pocket]

On 12/7/23 07:16, Greg Wooledge wrote:

On Wed, Dec 06, 2023 at 11:46:50PM -0600, David Wright wrote:

On Wed 06 Dec 2023 at 18:16:42 (-0500), Pocket wrote:

Which BTW this whole discussion about timezones is just water over the dam.

The system should be set to UTC, the "timezone" issue is really just a
"human" issue as the UTC clock is always correct

While I'm glad we're not discussing whether or not the RTC is set to
UTC or TAI or local time, I do want my computers to display to /me/ the
correct date and time corresponding to my location. And when I travel,
I expect my phone to switch its display automatically, using some
reasonably up-to-date tables.

I haven't had time to read and follow up on Pocket's list of references,
but I'd like to respond to these points with a real anecdote.

One of our systems at work uses a database with a web front end, where
users input the starting and ending times of medical tests that have
been performed on a patient.  When the tests are finished, and all the
data have been entered, billing charges are generated, and these charges
depend on the length of the test.

You'd think that you can determine the length of the test by subtracting
the start time from the end time, right?  Unfortunately, that fails
two times a year, if you don't do it exactly right.  The naive approach
of simply looking at the time field ("test started at 01:45 and ended
at 03:15 the same day, so it must have lasted 90 minutes") is wrong.
You have to look at the entire date-plus-time as a single timestamp,
and interpret it within the correct time zone.  That test might have been
90 minutes, or it might have been 30 minutes, or it might have been 150
minutes, depending on whether a DST transition happened in that interval,
and which way the clock moved.

I *literally* had to fix that bug (in March).  This isn't hypothetical.



I worked with time keeping systems for a major player in the business 
back in 1995.


That feature of the government reared its ugly head back then as well.

People get more irate when they are not payed properly then they are 
from being over billed,


trust me been there done that.




Of course, the system I'm dealing with only covers tests that have been
performed recently, not tests from a century ago.  So the historical
interpretation of times under previous government DST rules *is*
hypothetical as far as this anecdote goes.  But I hope some of you can
appreciate it nonetheless.


--
It's not easy to be me

Re: ntpsec as server questions

[Greg Wooledge]

On Wed, Dec 06, 2023 at 11:46:50PM -0600, David Wright wrote:
> On Wed 06 Dec 2023 at 18:16:42 (-0500), Pocket wrote:
> > Which BTW this whole discussion about timezones is just water over the dam.
> > 
> > The system should be set to UTC, the "timezone" issue is really just a
> > "human" issue as the UTC clock is always correct
> 
> While I'm glad we're not discussing whether or not the RTC is set to
> UTC or TAI or local time, I do want my computers to display to /me/ the
> correct date and time corresponding to my location. And when I travel,
> I expect my phone to switch its display automatically, using some
> reasonably up-to-date tables.

I haven't had time to read and follow up on Pocket's list of references,
but I'd like to respond to these points with a real anecdote.

One of our systems at work uses a database with a web front end, where
users input the starting and ending times of medical tests that have
been performed on a patient.  When the tests are finished, and all the
data have been entered, billing charges are generated, and these charges
depend on the length of the test.

You'd think that you can determine the length of the test by subtracting
the start time from the end time, right?  Unfortunately, that fails
two times a year, if you don't do it exactly right.  The naive approach
of simply looking at the time field ("test started at 01:45 and ended
at 03:15 the same day, so it must have lasted 90 minutes") is wrong.
You have to look at the entire date-plus-time as a single timestamp,
and interpret it within the correct time zone.  That test might have been
90 minutes, or it might have been 30 minutes, or it might have been 150
minutes, depending on whether a DST transition happened in that interval,
and which way the clock moved.

I *literally* had to fix that bug (in March).  This isn't hypothetical.

Of course, the system I'm dealing with only covers tests that have been
performed recently, not tests from a century ago.  So the historical
interpretation of times under previous government DST rules *is*
hypothetical as far as this anecdote goes.  But I hope some of you can
appreciate it nonetheless.

Re: ntpsec as server questions

[David Wright]

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
> > 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 
> federal law implementing Standard time
>  and
> Daylight saving time in the United States 
> .^[2]
>  It
> defined five time zones for the United States and authorized the
> 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.
> Tooltip
> Public Law (United States) 66–40
> , 41 Stat.
>  280
> , enacted August 20, 1919, over
> President Woodrow Wilson
> 's veto.
> 
> Section 264 of the act mistakenly placed most of the state of Idaho
>  (south of the Salmon River
> ) in UTC−06:00
>  CST (Central
> Standard Time ),
> but was amended in 2007 by Congress to UTC−07:00
>  MST (Mountain
> Standard Time
> ).^[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.

Re: ntpsec as server questions

[David Wright]

On Wed 06 Dec 2023 at 16:21:37 (-0500), James Cloos wrote:
> the current America/New_York equiv is:
> 
>   EST5EDT,M3.2.0/2:00:00,M11.1.0/2:00:00

That's as may be, but this discussion revolves around:

 "The M format is sufficient to describe many common daylight-savings
  transition laws. But note that none of these variants can deal with
  daylight-savings law changes, so in practice the historical data
  stored for named time zones (in the IANA time zone database) is
  necessary to interpret past time stamps correctly."

 (from some random POSIX Time Zone Specifications)

Cheers,
David.

Re: ntpsec as server questions

[David Wright]

On Wed 06 Dec 2023 at 18:16:42 (-0500), Pocket wrote:
> On 12/6/23 15:28, David Wright wrote:
> > Likely none for times present and future, unless Eric Adams should
> > pass a timezone bill. (In the 2010s, several U.S. states considered
> > legislation to move from the Eastern Time Zone to Atlantic Standard
> > Time, allegedly.)
> > 
> > But I've already posted an example in this thread where these
> > timezones give different answers:
> > 
> >https://lists.debian.org/debian-user/2023/12/msg00329.html
> > 
> Which BTW this whole discussion about timezones is just water over the dam.
> 
> The system should be set to UTC, the "timezone" issue is really just a
> "human" issue as the UTC clock is always correct

While I'm glad we're not discussing whether or not the RTC is set to
UTC or TAI or local time, I do want my computers to display to /me/ the
correct date and time corresponding to my location. And when I travel,
I expect my phone to switch its display automatically, using some
reasonably up-to-date tables.

Cheers,
David.

Re: ntpsec as server questions

[tomas]

On Wed, Dec 06, 2023 at 06:16:42PM -0500, Pocket wrote:
> 
> On 12/6/23 15:28, David Wright wrote:
> > Likely none for times present and future, unless Eric Adams should
> > pass a timezone bill [...]

> Which BTW this whole discussion about timezones is just water over the dam.

But still interesting and very much on-topic, because it invites us all to
question our incomplete and naive knowledge.

> The system should be set to UTC, the "timezone" issue is really just a
> "human" issue as the UTC clock is always correct

If we are picking nits, the system is set to UTX (aka "Unix time"), which
is, in itself, difficult to grasp and very near (but not equal) to UTC [1].

The closer you look the messier it gets. UTC, TAI, UT0, UT1... oh, my [2].

Cheers

[1] 
https://unix.stackexchange.com/questions/283164/unix-seconds-tai-si-seconds-leap-seconds-and-real-world-code
[2] http://www.stjarnhimlen.se/comp/time.html

-- 
t


signature.asc
Description: PGP signature

Re: ntpsec as server questions

[Pocket]

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
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  
federal law implementing Standard time 
 and Daylight 
saving time in the United States 
.^[2] 
 It defined 
five time zones for the United States and authorized the 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. 
Tooltip Public 
Law (United States) 66–40 
, 41 Stat. 
 280 
, enacted August 20, 1919, over 
President Woodrow Wilson 
's veto.


Section 264 of the act mistakenly placed most of the state of Idaho 
 (south of the Salmon River 
) in UTC−06:00 
 CST (Central Standard 
Time ), but was 
amended in 2007 by Congress to UTC−07:00 
 MST (Mountain Standard 
Time ).^[3] 
 MST 
was observed prior to the correction.




--
It's not easy to be me

Re: ntpsec as server questions

[Greg Wooledge]

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

Re: ntpsec as server questions

[Pocket]

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

Re: ntpsec as server questions

[Greg Wooledge]

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]

Re: ntpsec as server questions

[Pocket]

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

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 .

Looking at the actual tzdata source, as present in Debian

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

Re: ntpsec as server questions

[Greg Wooledge]

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

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 .

Looking at the actual tzdata source, as present in Debian

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.

Re: ntpsec as server questions

[Pocket]

On 12/6/23 18:28, Greg Wooledge wrote:

On Wed, Dec 06, 2023 at 02:50:50PM -0500, Pocket wrote:

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.

It's not just about your system's current time.  It's about timestamps
that you handle in any kind of software.  If you process dates and times
from the past, e.g. in a database application, and intend to display
them to humans, then you'll want to use a historically accurate timezone.

Which America/New_York is incorrect from 1918 to 1966, possibly into the 
1970s/80s depending upon your location in the Eastern Standard Time zone.



--
It's not easy to be me

Re: ntpsec as server questions

[Greg Wooledge]

On Wed, Dec 06, 2023 at 02:50:50PM -0500, Pocket wrote:
> 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.

It's not just about your system's current time.  It's about timestamps
that you handle in any kind of software.  If you process dates and times
from the past, e.g. in a database application, and intend to display
them to humans, then you'll want to use a historically accurate timezone.

Re: ntpsec as server questions

[Pocket]

On 12/6/23 15:28, David Wright wrote:

Likely none for times present and future, unless Eric Adams should
pass a timezone bill. (In the 2010s, several U.S. states considered
legislation to move from the Eastern Time Zone to Atlantic Standard
Time, allegedly.)

But I've already posted an example in this thread where these
timezones give different answers:

   https://lists.debian.org/debian-user/2023/12/msg00329.html

Cheers,
David.


Which BTW this whole discussion about timezones is just water over the dam.

The system should be set to UTC, the "timezone" issue is really just a 
"human" issue as the UTC clock is always correct


--
It's not easy to be me

Re: ntpsec as server questions

[Pocket]

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




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.

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,
 above), and the latter omits the period 1920–1966, except
for War Time and Peace Time (between  and ).


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
  

Re: ntpsec as server questions

[Pocket]


Sent from my iPad

> On Dec 6, 2023, at 1:28 PM, 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
> 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 

Re: ntpsec as server questions

[James Cloos]

the current America/New_York equiv is:

  EST5EDT,M3.2.0/2:00:00,M11.1.0/2:00:00

-JimC
-- 
James Cloos  OpenPGP: 0x997A9F17ED7DAEA6

Re: ntpsec as server questions

[David Wright]

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



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

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,
 above), and the latter omits the period 1920–1966, except
for War Time and Peace Time (between  and ).

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.

Re: ntpsec as server questions

[David Wright]

On Wed 06 Dec 2023 at 12:06:04 (-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

Time zones are a civil and legal matter, so non-authoritative would
mean that the tz database would not be evidence in a court of law.

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

We all depend on there being a standard to live our daily lives.
It's only when you start compiling all the standards that have been
and will be used that it starts to resemble "chaos", particularly
in some parts of the world. (The US appears to have been one of
those areas in the not so distant past.)

Fixes and enhancements means that as changes are reported or
discovered, the database is corrected. There's a constant trickle
of future changes being made by governments. People also discover
historical inaccuracies from literature, like old legal documents
and newspaper archives. I respect their research.

On Wed 06 Dec 2023 at 13:02:45 (-0500), Pocket wrote:

> TZ=POSIX;date
> Wed Dec  6 18:00:38 POSIX 2023

You've got a choice of writing something like posix/America/New_York
or posixrules, though IDK where the last name came from. (I don't
think it can be New Jersey on this occasion.)

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

Likely none for times present and future, unless Eric Adams should
pass a timezone bill. (In the 2010s, several U.S. states considered
legislation to move from the Eastern Time Zone to Atlantic Standard
Time, allegedly.)

But I've already posted an example in this thread where these
timezones give different answers:

  https://lists.debian.org/debian-user/2023/12/msg00329.html

Cheers,
David.

Re: ntpsec as server questions

[Greg Wooledge]

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.

Re: ntpsec as server questions

[Pocket]

On 12/6/23 12:55, Greg Wooledge wrote:

On Wed, Dec 06, 2023 at 05:40:00PM -, 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

Re: ntpsec as server questions

[Greg Wooledge]

On Wed, Dec 06, 2023 at 05:40:00PM -, 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.

Re: ntpsec as server questions

[Curt]

On 2023-12-06, Max Nikulin  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/

Re: ntpsec as server questions

[Pocket]

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

Re: ntpsec as server questions

[Greg Wooledge]

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.

Re: ntpsec as server questions

[Pocket]

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

Re: ntpsec as server questions

[Greg Wooledge]

On Wed, Dec 06, 2023 at 11:28:40AM -0500, Pocket wrote:
> diff /usr/share/zoneinfo/EST5EDT /usr/share/zoneinfo/America/New_York
> Binary files /usr/share/zoneinfo/EST5EDT and
> /usr/share/zoneinfo/America/New_York differ

unicorn:/usr/share/zoneinfo$ ls -l EST5EDT
-rw-r--r-- 1 root root 2310 May 28  2023 EST5EDT

unicorn:/usr/share/zoneinfo$ ls -l America/New_York 
-rw-r--r-- 1 root root 3552 May 28  2023 America/New_York

unicorn:/usr/share/zoneinfo$ file EST5EDT 
EST5EDT: timezone data (fat), version 2, 5 gmt time flags, 5 std time flags, no 
leap seconds, 149 transition times, 5 local time types, 16 abbreviation chars

unicorn:/usr/share/zoneinfo$ file America/New_York 
America/New_York: timezone data (fat), version 2, 6 gmt time flags, 6 std time 
flags, no leap seconds, 236 transition times, 6 local time types, 20 
abbreviation chars

OK, they are definitely not the same.  I don't feel like digging through
them to try to figure out *what* the differences are, but clearly there
must be *some* point(s) in time where they give different results.

If you wish to continue using the legacy time zone, knowing that it's
different from the proper one (but not precisely in what way), then on
your own head be it.

For comparison, this one is cleary safe to use:

unicorn:/usr/share/zoneinfo$ ls -l US/Eastern
lrwxrwxrwx 1 root root 19 May 28  2023 US/Eastern -> ../America/New_York

Re: ntpsec as server questions

[Max Nikulin]

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.

Re: ntpsec as server questions

[Curt]

On 2023-12-06, Greg Wooledge  wrote:
>
> Honestly, I don't see the appeal of using legacy time zone names.  Is
> it just for the sake of contrariness?
>

No lack of contrariness around here. There exists such a thing as putting too
fine a point on a thing, a notion which appears to escape some technical
mentalities.

In defence of time zones (they don't really need it, I guess):

 Why are the clocks in Urumqi, China, so far out of kilter with the cycles of
 the sun? Because of a legacy of Mao Zedong and the Communist Party’s desire for
 unified control. Though China is almost as wide as the continental United
 States, the whole country is officially in just one time zone — Beijing time.

 So when it’s 7 a.m. in the Forbidden City, it’s also officially 7 a.m. 2,000
 miles to the west in Urumqi, the capital of the Xinjiang region — even if the
 stars are still out there.

 That can lead to headaches — and lost sleep. “It’s hard to adjust,” says Gao
 Li, a sanitation worker in Urumqi. “I often think we must be the only people
 who eat dinner at midnight.”
 
 So schools, airports and train stations operate at odd hours; national exams
 are sometimes given in the dead of night; and restaurants stay open for dinner
 into the wee hours.

 The eccentricities of the clock also tend to divide people in Xinjiang by
 ethnicity. The Uighurs, Turkic-speaking Muslims who consider the region their
 homeland, tend to set their clocks two hours earlier, to more closely match the
 local day. But the Han Chinese who live there, members of China’s predominant
 ethnic group, generally follow Beijing time. The discrepancies can be a source
 of confusion and frustration, especially for younger people who frequently
 socialize across ethnic lines.

https://www.nytimes.com/2016/06/17/world/asia/china-single-time-zone.html

Re: ntpsec as server questions

[Pocket]

On 12/6/23 11:18, Greg Wooledge wrote:

On Wed, Dec 06, 2023 at 10:44:42AM -0500, Pocket wrote:

Well POSIX has worked for me since the days of Xenix and System V.

Well, most of the goofy time zone changes were all *before* that.  But
there's at least one that happened more recently

unicorn:~$ TZ=EST5EDT date -d '2006-03-12 +4 hours'
Sun Mar 12 04:00:00 EST 2006

unicorn:~$ TZ=EST5EDT date -d '2007-03-11 +4 hours'
Sun Mar 11 05:00:00 EDT 2007

So, OK, I guess the EST5EDT time zone in Debian 12 properly handles
the change to start of DST in the US in 2007 (and more specifically,
handles dates *older* than that using the historic rules instead of
the current rules).

Looking at other periods of interest from Wikipedia:

unicorn:~$ TZ=EST5EDT date -d '1987-04-05 +4 hours'
Sun Apr  5 05:00:00 EDT 1987

unicorn:~$ TZ=EST5EDT date -d '1974-01-06 +4 hours'
Sun Jan  6 05:00:00 EDT 1974

unicorn:~$ TZ=EST5EDT date -d '1967-04-30 +4 hours'
Sun Apr 30 05:00:00 EDT 1967

I guess EST5EDT in Debian 12 is more like a synonym for America/New_York
than a real historical EST5EDT as described by Erik Naggum
.

If this is satisfactory, then you can continue using the legacy time
zone without running into problems.  At least on current Debian systems.
I wouldn't know how well-behaved that time zone is on other systems.



I used POSIX time zones on other systems including my custom scratch 
built ones.


The custom built systems was built using a cross compiler for the AMD64, 
aarch64 and armv7a platforms.


Never had an issue.

Don't see what the issue is here?




Honestly, I don't see the appeal of using legacy time zone names.  Is
it just for the sake of contrariness?


diff /usr/share/zoneinfo/EST5EDT /usr/share/zoneinfo/America/New_York
Binary files /usr/share/zoneinfo/EST5EDT and 
/usr/share/zoneinfo/America/New_York differ


Because I can ;}


--
It's not easy to be me

Re: ntpsec as server questions

[Greg Wooledge]

On Wed, Dec 06, 2023 at 10:44:42AM -0500, Pocket wrote:
> Well POSIX has worked for me since the days of Xenix and System V.

Well, most of the goofy time zone changes were all *before* that.  But
there's at least one that happened more recently

unicorn:~$ TZ=EST5EDT date -d '2006-03-12 +4 hours'
Sun Mar 12 04:00:00 EST 2006

unicorn:~$ TZ=EST5EDT date -d '2007-03-11 +4 hours'
Sun Mar 11 05:00:00 EDT 2007

So, OK, I guess the EST5EDT time zone in Debian 12 properly handles
the change to start of DST in the US in 2007 (and more specifically,
handles dates *older* than that using the historic rules instead of
the current rules).

Looking at other periods of interest from Wikipedia:

unicorn:~$ TZ=EST5EDT date -d '1987-04-05 +4 hours'
Sun Apr  5 05:00:00 EDT 1987

unicorn:~$ TZ=EST5EDT date -d '1974-01-06 +4 hours'
Sun Jan  6 05:00:00 EDT 1974

unicorn:~$ TZ=EST5EDT date -d '1967-04-30 +4 hours'
Sun Apr 30 05:00:00 EDT 1967

I guess EST5EDT in Debian 12 is more like a synonym for America/New_York
than a real historical EST5EDT as described by Erik Naggum
.

If this is satisfactory, then you can continue using the legacy time
zone without running into problems.  At least on current Debian systems.
I wouldn't know how well-behaved that time zone is on other systems.

Honestly, I don't see the appeal of using legacy time zone names.  Is
it just for the sake of contrariness?

Re: ntpsec as server questions

[Pocket]

On 12/6/23 10:07, Max Nikulin wrote:

On 06/12/2023 20:08, Pocket wrote:

On 12/6/23 07:22, Max Nikulin wrote:

On 06/12/2023 00:03, Pocket wrote:

On 12/5/23 11:37, Max Nikulin wrote:

 dpkg-reconfigure tzdata


That does not work. Cannot set EST5EDT.  you have to do that manually.


Do you have reasons to prefer EST5EDT to IANA identifiers like 
America/Detroit, America/New_York, etc. (that have some differences 
from EST5EDT)? Location-based time zones should be more precise for 
most of users.

[...]

I follow POSIX


There are enough oversights in various standards. When accurate time 
zone DB is unavailable, POSIX ones might be used (if risk to get wrong 
results is accepted). Otherwise, from my of view, it is a legacy to 
keep aside and a kind of cargo cult. That is why I asked concerning 
your reasons.



Well POSIX has worked for me since the days of Xenix and System V.





I introduced EST5DST to this by simply posted my configuration.


Maybe due to language barrier I perceived it as a recommendation for 
Gene. The same time zone appeared earlier in a Gene's message. Perhaps 
he still has it as the /etc/localtime link target. Of course, you are 
free to have whatever you want in your configuration. Please, be 
responsible suggesting anything to others.



I post what works for and the information I have found due to my research.

It doesn't mean what I use will work or solve others issues.

If it offends you then so be it.


Many times I will research an issue and NOT use what others posted as it 
doesn't work for me.


I may end up finding my own solution.




Do you really need TZ environment variable especially set to the 
value in system-wide configuration?

[...]
I doesn't hurt anything, What if I install some application that uses 
it and it is not set?


It may cause waste of time when you will need to change time zone. If 
not all occurrences are updated you may see wrong time. For me it is a 
reason to avoid unnecessary settings.



Which is why I use a script to change it





cat /etc/default/locale
LANG=POSIX


Does it set UTF-8 encoding? Sometimes I use C.UTF-8. However there are 
enough subtle differences (sorting, etc.) from any en_* locale.





locale charmap
ANSI_X3.4-1968

--
It's not easy to be me

Re: ntpsec as server questions

[Max Nikulin]

On 06/12/2023 20:08, Pocket wrote:

On 12/6/23 07:22, Max Nikulin wrote:

On 06/12/2023 00:03, Pocket wrote:

On 12/5/23 11:37, Max Nikulin wrote:

 dpkg-reconfigure tzdata


That does not work. Cannot set EST5EDT.  you have to do that manually.


Do you have reasons to prefer EST5EDT to IANA identifiers like 
America/Detroit, America/New_York, etc. (that have some differences 
from EST5EDT)? Location-based time zones should be more precise for 
most of users.

[...]

I follow POSIX


There are enough oversights in various standards. When accurate time 
zone DB is unavailable, POSIX ones might be used (if risk to get wrong 
results is accepted). Otherwise, from my of view, it is a legacy to keep 
aside and a kind of cargo cult. That is why I asked concerning your reasons.



I introduced EST5DST to this by simply posted my configuration.


Maybe due to language barrier I perceived it as a recommendation for 
Gene. The same time zone appeared earlier in a Gene's message. Perhaps 
he still has it as the /etc/localtime link target. Of course, you are 
free to have whatever you want in your configuration. Please, be 
responsible suggesting anything to others.


Do you really need TZ environment variable especially set to the value 
in system-wide configuration?

[...]
I doesn't hurt anything, What if I install some application that uses it 
and it is not set?


It may cause waste of time when you will need to change time zone. If 
not all occurrences are updated you may see wrong time. For me it is a 
reason to avoid unnecessary settings.



cat /etc/default/locale
LANG=POSIX


Does it set UTF-8 encoding? Sometimes I use C.UTF-8. However there are 
enough subtle differences (sorting, etc.) from any en_* locale.

Re: ntpsec as server questions

[Pocket]

On 12/6/23 07:22, Max Nikulin wrote:

On 06/12/2023 00:03, Pocket wrote:

On 12/5/23 11:37, Max Nikulin wrote:

On 05/12/2023 05:14, Pocket wrote:



For gene

[...]


 dpkg-reconfigure tzdata


That does not work. Cannot set EST5EDT.  you have to do that manually.


Do you have reasons to prefer EST5EDT to IANA identifiers like 
America/Detroit, America/New_York, etc. (that have some differences 
from EST5EDT)? Location-based time zones should be more precise for 
most of users.


I find it reasonable that "dpkg-reconfigure tzdata" forces users to 
set a timezone that should provide more accurate results for them.



I follow POSIX




I have seen America/New_York in a couple of Gene's messages including
https://lists.debian.org/msgid-search/7ba9b8bc-2929-4a3d-8007-a1b5c7f6f...@shentel.net 

so I assume it is one that he should use. My impression is that 
EST5EDT appeared unintentionally.




I introduced EST5DST to this by simply posted my configuration.



I don't use KDE, I am using LXDE and systems without desktops.

Comment that part out of the shell script.


Do you really need TZ environment variable especially set to the value 
in system-wide configuration? In the Gene's case I mentioned it for 
the case that some piece of software decided to set it, but I have not 
recommended to set it. It is a way to make debugging of a next issue 
harder.




I doesn't hurt anything, What if I install some application that uses it 
and it is not set?



Sorry, I do not have a VM with LXDE to check if TZ is actually set for 
applications. It may depend on display manager configuration and on 
the approach to launch applications: window manager children or 
systemd session.


Anyway I noticed "For gene" and I remember that he uses KDE that has a 
GUI for it. However I am unsure if KDE is installed to this 3d printer 
controller.



Which is why I use it.

/usr/share/zoneinfo/posix/EST5EDT is a symlilnk to 
/usr/share/zoneinfo/EST5EDT


And it is rather confusing since arbitrary abbreviations may be used 
to specify POSIX time zones, e.g. ABC5DEF. From my point of view, it 
is just legacy since the time zone database is available.


It was painful when JavaScript (ECMAScript 5) had fixed DST rules 
based on current regulations. Chrome followed the standard, Firefox 
used accurate history of time transitions. I have not checked POSIX, 
but I see that GNU libc approach is something third in between.


Let's use time zones that allows to get accurate local time.


You use want works for you I will use what works for me.

Anyway I will use the timezone that I wish to use and that is EST5EDT.  
All my systems are set to POSIX standards.


cat /etc/default/locale
LANG=POSIX

Re: ntpsec as server questions

[Max Nikulin]

On 06/12/2023 00:03, Pocket wrote:

On 12/5/23 11:37, Max Nikulin wrote:

On 05/12/2023 05:14, Pocket wrote:



For gene

[...]


 dpkg-reconfigure tzdata


That does not work. Cannot set EST5EDT.  you have to do that manually.


Do you have reasons to prefer EST5EDT to IANA identifiers like 
America/Detroit, America/New_York, etc. (that have some differences from 
EST5EDT)? Location-based time zones should be more precise for most of 
users.


I find it reasonable that "dpkg-reconfigure tzdata" forces users to set 
a timezone that should provide more accurate results for them.


I have seen America/New_York in a couple of Gene's messages including
https://lists.debian.org/msgid-search/7ba9b8bc-2929-4a3d-8007-a1b5c7f6f...@shentel.net
so I assume it is one that he should use. My impression is that EST5EDT 
appeared unintentionally.



I don't use KDE, I am using LXDE and systems without desktops.

Comment that part out of the shell script.


Do you really need TZ environment variable especially set to the value 
in system-wide configuration? In the Gene's case I mentioned it for the 
case that some piece of software decided to set it, but I have not 
recommended to set it. It is a way to make debugging of a next issue harder.


Sorry, I do not have a VM with LXDE to check if TZ is actually set for 
applications. It may depend on display manager configuration and on the 
approach to launch applications: window manager children or systemd session.


Anyway I noticed "For gene" and I remember that he uses KDE that has a 
GUI for it. However I am unsure if KDE is installed to this 3d printer 
controller.



Which is why I use it.

/usr/share/zoneinfo/posix/EST5EDT is a symlilnk to 
/usr/share/zoneinfo/EST5EDT


And it is rather confusing since arbitrary abbreviations may be used to 
specify POSIX time zones, e.g. ABC5DEF. From my point of view, it is 
just legacy since the time zone database is available.


It was painful when JavaScript (ECMAScript 5) had fixed DST rules based 
on current regulations. Chrome followed the standard, Firefox used 
accurate history of time transitions. I have not checked POSIX, but I 
see that GNU libc approach is something third in between.


Let's use time zones that allows to get accurate local time.

Re: ntpsec as server questions

[David Wright]

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.

Re: ntpsec as server questions

[Pocket]

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

Re: ntpsec as server questions

[gene heskett]

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

Re: ntpsec as server questions

[Pocket]

On 12/5/23 11:37, 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 does not work. Cannot set EST5EDT.  you have to do that manually.

You also can not select any of the POSIX time zones which indecently 
EST5EDT is one of those



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 don't use KDE, I am using LXDE and systems without desktops.

Comment that part out of the shell script.


I script all my setups, so I can apply them to all the systems I have.

For example:

openssh-server.sh

bind.sh

nginx.sh

nfs-client.sh

nfs-server.sh

The scripts install the debian packages required and then setup the 
configuration.





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.


LANG=C.UTF-8 TZ=EST5EDT date -d 'TZ="Z" 1940-01-01 00:00'
Sun Dec 31 19:00:00 EST 1939

LANG=C.UTF-8 TZ=EST5EDT date -d 'TZ="Z" 1943-01-01 00:00'
Thu Dec 31 20:00:00 EWT 1942

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



Which is why I use it.

/usr/share/zoneinfo/posix/EST5EDT is a symlilnk to 
/usr/share/zoneinfo/EST5EDT





https://naggum.no/lugm-time.html
Erik Naggum. A Long, Painful History of Time. 1999

8.2 Timezone Representation

David Olsen 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 Olsen's approach is to maintain tables of
all the timezone changes.





--
It's not easy to be me

Re: ntpsec as server questions

[Max Nikulin]

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.


LANG=C.UTF-8 TZ=EST5EDT date -d 'TZ="Z" 1940-01-01 00:00'
Sun Dec 31 19:00:00 EST 1939

LANG=C.UTF-8 TZ=EST5EDT date -d 'TZ="Z" 1943-01-01 00:00'
Thu Dec 31 20:00:00 EWT 1942

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


https://naggum.no/lugm-time.html
Erik Naggum. A Long, Painful History of Time. 1999

8.2 Timezone Representation

David Olsen 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 Olsen's approach is to maintain tables of
all the timezone changes.

Re: ntpsec as server questions

[David Wright]

On Mon 04 Dec 2023 at 16:24:11 (-0500), gene heskett wrote:
> On 12/4/23 11:31, Dan Purgert wrote:
> > On Dec 04, 2023, gene heskett wrote:
> > > [...]
> > > So here on coyote: date -u:
> > > Mon Dec  4 15:47:44 UTC 2023
> > > but on mkspi: date -u:
> > > Mon 04 Dec 2023 03:47:16 PM UTC
> > > [...]
> > > 
> > > WTH?  Where is that false 12 hour offset coming from?
> > 
> > Coyote seems to use the standard output of 'date' (in 24-hour clock
> > format).
> > 
> > mkspi /appears/ to be using an approximation of "-R" ("--rfc-email",
> > as set in RFC5322), though it's missing the comma between "Mon" and "04
> > Dec", and is set in 12-hour mode.
> > 
> > It's been ages since I've dug into it, but I _BELIEVE_ the LC_TIME
> > environment variable has an effect here. (Or had, at some point in the
> > past).
> It might well be, Dan but no man page,

They're all documented together in   man locale, with examples:

  $ man locale | grep -A25 EXAMPLES
  EXAMPLES
   $ locale
   LANG=en_US.UTF-8
   LC_CTYPE="en_US.UTF-8"
   LC_NUMERIC="en_US.UTF-8"
   LC_TIME="en_US.UTF-8"
   LC_COLLATE="en_US.UTF-8"
   LC_MONETARY="en_US.UTF-8"
   LC_MESSAGES="en_US.UTF-8"
   LC_PAPER="en_US.UTF-8"
   LC_NAME="en_US.UTF-8"
   LC_ADDRESS="en_US.UTF-8"
   LC_TELEPHONE="en_US.UTF-8"
   LC_MEASUREMENT="en_US.UTF-8"
   LC_IDENTIFICATION="en_US.UTF-8"
   LC_ALL=

   $ locale date_fmt
   %a %b %e %H:%M:%S %Z %Y

   $ locale -k date_fmt
   date_fmt="%a %b %e %H:%M:%S %Z %Y"

   $ locale -ck date_fmt
   LC_TIME
   date_fmt="%a %b %e %H:%M:%S %Z %Y"
  $ 

Set for "C" in the env output.
> I redirected the /etc/localtime link to EST5EDT and fixed it, the
> thing thought it was in the 3rd worst hell hole in the US, LA, CA.

Please—no.

Cheers,
David.

Re: ntpsec as server questions

[David Wright]

On Mon 04 Dec 2023 at 15:28:03 (-0500), gene heskett wrote:
> On 12/4/23 07:17, Greg Wooledge wrote:
> 
> > > ls -hal /etc/localtime
> > > lrwxrwxrwx 1 root root 27 Nov  1 18:21 /etc/localtime ->
> > > /usr/share/zoneinfo/EST5EDT
> 
> And using mc to edit that link fixed it, I am now getting the correct
> time from date, thank you a lot.
> 
> But maybe a bug against tzselect s/b filed, IMNSHO it should have
> fixed that. It did not.

If by fixed, you mean it should have changed the time zone of the
machine, you obviously didn't read the man page:

  Note that tzselect will not actually change the timezone for you.
  Use 'dpkg-reconfigure tzdata' to achieve this.

nor the output from the program:

  $ tzselect 
  Please identify a location so that time zone rules can be set correctly.
  Please select a continent, ocean, "coord", or "TZ".
   1) Africa
   2) Americas
   3) Antarctica
   4) Asia
   5) Atlantic Ocean
   6) Australia
   7) Europe
   8) Indian Ocean
   9) Pacific Ocean
  10) coord - I want to use geographical coordinates.
  11) TZ - I want to specify the timezone using the Posix TZ format.
  #? 11
  Please enter the desired value of the TZ environment variable.
  For example, AEST-10 is abbreviated AEST and is 10 hours
  ahead (east) of Greenwich, with no daylight saving time.
  EST5EDT

  The following information has been given:

TZ='EST5EDT'

  Therefore TZ='EST5EDT' will be used.
  Selected time is now:   Mon Dec  4 21:42:03 EST 2023.
  Universal Time is now:  Tue Dec  5 02:42:03 UTC 2023.
  Is the above information OK?
  1) Yes
  2) No
  #? 1

  You can make this change permanent for yourself by appending the line
 

  TZ='EST5EDT'; export TZ
  to the file '.profile' in your home directory; then log out and log in again.
↑↑↑

  Here is that TZ value again, this time on standard output so that you
  can use the /usr/bin/tzselect command in shell scripts:
  EST5EDT
  $ 

(I've assumed you want the old value rather than America/New_York.)

Cheers,
David.

Re: ntpsec as server questions

[jeremy ardley]

On 5/12/23 04:52, Darac Marjal wrote:


Most people know what timezone they're currently in, but the more 
likely know what their nearest city is. Cities rarely change, but 
timezones do. Take the example of Triana in Paul Eggert's original 
email. The city never moved, but the timezone it was it changed dozens 
of times. Its a lot easier for someone to configure Europe/Tirana than 
to have to keep changing timezones. 



The problem with that approach is when reviewing historical events there 
is no easy way to know what the local time was at any specific date


This is precisely the same problem as daylight saving which afflicts a 
large number of cities, though easier to pin the time down.


In my country we have different names for daylight saving time and 
normal time. e.g. Sydney Australia is AEDT at the moment while a few 
months ago it was AEST


If I referred to timezone Australia/Sydney I'd have to go and look up 
the daylight saving dates.


In my hometown of Perth we had daylight saving for a bit but gave up on 
it. So Australia/Perth timezone is fixed at AWST  but at dates I don't 
precisely recall could have been AWDT

Re: ntpsec as server questions

[Pocket]

On 12/4/23 15:28, gene heskett wrote:

On 12/4/23 07:17, Greg Wooledge wrote:


ls -hal /etc/localtime
lrwxrwxrwx 1 root root 27 Nov  1 18:21 /etc/localtime ->
/usr/share/zoneinfo/EST5EDT


And using mc to edit that link fixed it, I am now getting the correct 
time from date, thank you a lot.


But maybe a bug against tzselect s/b filed, IMNSHO it should have 
fixed that. It did not.


Cheers, Gene Heskett.



For gene..

#!/usr/bin/dash
#-
#    Title: timezone.sh
#    Date: 2023-12-04
#    Version: 1.0
#    Author: poc...@columbus.rr.com
#-
set -o errexit    # exit if error...insurance ;)
set -o nounset    # exit if variable not initialized
#-
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
chmod +x "$profile"/timezone.sh
#-

chmod +x timezone.sh

sudo ./timezone.sh


--
It's not easy to be me

Re: ntpsec as server questions

[David Wright]

On Mon 04 Dec 2023 at 15:36:32 (-0500), Greg Wooledge wrote:
> I classify time zone names into three historic eras.  In the oldest era,
> you have zone names like EST5EDT which are composed of three pieces.
> The first piece, EST, is the zone's name when the clock is "normal" (not
> daylight saving or summer time).  The second piece, 5, is the number
> of hours behind GMT the clock is (normally).  The third piece, EDT, is
> the zone's name when daylight saving time is in effect.
> 
> In the second era, zone names look like "US/Eastern".  The piece on the
> right hand side is a component of the piece on the left.  I'm uncertain
> whether the pieces on the left are always country codes, or if there's
> some other arrangement.
> 
> In the modern era, zone names look like "America/Chicago".  The piece on
> the left is a continent (or other large geographic region, e.g. "Pacific"),
> and the piece on the right is a major city, preferably *the* major city,
> which exemplifies the specific time zone in question.
> 
> For you and me, the current era time zone name is "America/New_York".
> This is how the Debian installer sets the localtime symlink, and is
> what we should be using if we have to set it ourselves.
> 
> I personally find "US/Eastern" the easiest to grasp, and I'm sad that
> this pattern fell out of fashion, for whatever reason.  Whenever I tell
> people on the Internet (who may not be Linux users) what time zone I'm
> in, I always go with "US/Eastern".  It's just so *clear*.

Because they don't work historically; for example, say you live in
Wayne Co, KY:

/usr/share/zoneinfo$ for j in America/Kentucky/*; do TZ="$j" date -d 
'@907654321'; done
Tue Oct  6 02:12:01 EDT 1998
Tue Oct  6 01:12:01 CDT 1998
/usr/share/zoneinfo$ for j in America/Kentucky/*; do TZ="$j" date -d 
'@987654321'; done
Thu Apr 19 00:25:21 EDT 2001
Thu Apr 19 00:25:21 EDT 2001
/usr/share/zoneinfo$ 

Cheers,
David.

Re: ntpsec as server questions

[gene heskett]

On 12/4/23 14:17, Greg Wooledge wrote:

On Mon, Dec 04, 2023 at 02:11:51PM -0500, gene heskett wrote:

That leave the localtime error pretty much up to the date command, or is
there something else screwing with this? Where ALL in this chain does
/etc/timezone get used, which is currently set to:
America/New_York


ls -ld /etc/*time*

Please.

.

as reported, its now fixed.
root@mkspi:/usr/share/zoneinfo# ls -ld /etc/*time*
lrwxrwxrwx 1 root root 27 Dec  4 15:22 /etc/localtime -> 
/usr/share/zoneinfo/EST5EDT

-rw-r--r-- 1 root root 17 Dec  4 11:44 /etc/timezone

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

Re: ntpsec as server questions

[gene heskett]

On 12/4/23 11:39, John Hasler wrote:

Gene writes:

Thats says this machine has it hdware clock on utc.


No.  That says that the system clock (not the hardware clock) is
synchronized to NTP time. The system clock keeps UNIX time: seconds
since the epoch.  It is converted to either UTC or local time as
approporiate for display.  It says nothing about the hardware clock.

Try

 hwclock -l

to find out what timezone the hardwareclock is set to.

If the box is running systemd try

timedatectl


Its ( the printer ) is still buster, so that conversion is incomplete. 
Thanks John.





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

Re: ntpsec as server questions

[gene heskett]

On 12/4/23 11:34, Greg Wooledge wrote:

On Mon, Dec 04, 2023 at 10:55:47AM -0500, gene heskett wrote:

root@mkspi:/etc# chronyc sources
210 Number of sources = 1
MS Name/IP address Stratum Poll Reach LastRx Last sample

===
^* coyote.coyote.den 2   61742-22us[  -25us] +/-
41ms


I've never used chrony, but that looks good at first glance.


root@mkspi:/etc# date
Mon 04 Dec 2023 07:34:59 AM PST
its 10:35 here, still 3 hours off.


The time is *correct*, it's just being reported for a different time
zone than you want.


So here on coyote: date -u:
Mon Dec  4 15:47:44 UTC 2023
but on mkspi: date -u:
Mon 04 Dec 2023 03:47:16 PM UTC


Again, both correct.


WTH?  Where is that false 12 hour offset coming from?


There is no 12 hour offset.  One is being reported in 24-hour time, and
the other in 12-hour time (it says "PM"), because of different locale
definitions.

All you need to do is change your system's default time zone, which on
Debian involves changing the *file* /etc/timezone and the *symlink*
/etc/localtime.  Both are required, because some programs use one and
some use the other.

We've said this in like 3 other emails so far.


True, but I don't recall /etc/localtime until today. I thank you again.


.


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

Re: ntpsec as server questions

[gene heskett]

On 12/4/23 11:31, Dan Purgert wrote:

On Dec 04, 2023, gene heskett wrote:

[...]
So here on coyote: date -u:
Mon Dec  4 15:47:44 UTC 2023
but on mkspi: date -u:
Mon 04 Dec 2023 03:47:16 PM UTC
[...]

WTH?  Where is that false 12 hour offset coming from?


Coyote seems to use the standard output of 'date' (in 24-hour clock
format).

mkspi /appears/ to be using an approximation of "-R" ("--rfc-email",
as set in RFC5322), though it's missing the comma between "Mon" and "04
Dec", and is set in 12-hour mode.

It's been ages since I've dug into it, but I _BELIEVE_ the LC_TIME
environment variable has an effect here. (Or had, at some point in the
past).

It might well be, Dan but no man page, Set for "C" in the env output.
I redirected the /etc/localtime link to EST5EDT and fixed it, the thing 
thought it was in the 3rd worst hell hole in the US, LA, CA.




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

Re: ntpsec as server questions

[Darac Marjal]

On 04/12/2023 20:36, Greg Wooledge wrote:

On Mon, Dec 04, 2023 at 03:19:33PM -0500, gene heskett wrote:

On 12/4/23 07:17, Greg Wooledge wrote:

ls -hal /etc/localtime

Aha! You found it, but how do I change it?
root@mkspi:/etc# cat timezone
America/New_York
root@mkspi:/etc# ls -hal /etc/localtime
lrwxrwxrwx 1 root root 39 Jul 25  2022 /etc/localtime ->
/usr/share/zoneinfo/America/Los_Angeles

It's just a symbolic link.  It looks like you have the "modern" style
of zone names, so:

 ln -sf /usr/share/zoneinfo/America/New_York /etc/localtime


use mc to edit the /etc/localtime link?  Surely there is  better way...

I don't know how mc works.  I've never used it.  If that can change the
target of a symlink, similar to running "ln -sf", then you may use it.


The string as the last few
bytes of posixrules looks correct at EST5EDT, and I've got a headache.
there are links to links to links in that midden heap.

I classify time zone names into three historic eras.  In the oldest era,
you have zone names like EST5EDT which are composed of three pieces.
The first piece, EST, is the zone's name when the clock is "normal" (not
daylight saving or summer time).  The second piece, 5, is the number
of hours behind GMT the clock is (normally).  The third piece, EDT, is
the zone's name when daylight saving time is in effect.

In the second era, zone names look like "US/Eastern".  The piece on the
right hand side is a component of the piece on the left.  I'm uncertain
whether the pieces on the left are always country codes, or if there's
some other arrangement.

In the modern era, zone names look like "America/Chicago".  The piece on
the left is a continent (or other large geographic region, e.g. "Pacific"),
and the piece on the right is a major city, preferably *the* major city,
which exemplifies the specific time zone in question.

For you and me, the current era time zone name is "America/New_York".
This is how the Debian installer sets the localtime symlink, and is
what we should be using if we have to set it ourselves.

I personally find "US/Eastern" the easiest to grasp, and I'm sad that
this pattern fell out of fashion, for whatever reason.  Whenever I tell
people on the Internet (who may not be Linux users) what time zone I'm
in, I always go with "US/Eastern".  It's just so *clear*.


According to https://mm.icann.org/pipermail/tz/1993-October/009233.html, 
it was Paul Eggert who proposed this new system. I suspect the subtlety 
between the two systems is: Do you want to specify the timezone, or do 
you want the database to track the timezones for you? Or, to put it 
another way, do you want to specify the time offset, do you want to 
specify the (current) timezone, or do you want the database to track it 
for you?


Most people know what timezone they're currently in, but the more likely 
know what their nearest city is. Cities rarely change, but timezones do. 
Take the example of Triana in Paul Eggert's original email. The city 
never moved, but the timezone it was it changed dozens of times. Its a 
lot easier for someone to configure Europe/Tirana than to have to keep 
changing timezones.


If you happen to live somewhere where the timezone has been stable, 
consider yourself privileged.






OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: ntpsec as server questions

[Greg Wooledge]

On Mon, Dec 04, 2023 at 03:19:33PM -0500, gene heskett wrote:
> On 12/4/23 07:17, Greg Wooledge wrote:
> > ls -hal /etc/localtime
> 
> Aha! You found it, but how do I change it?
> root@mkspi:/etc# cat timezone
> America/New_York
> root@mkspi:/etc# ls -hal /etc/localtime
> lrwxrwxrwx 1 root root 39 Jul 25  2022 /etc/localtime ->
> /usr/share/zoneinfo/America/Los_Angeles

It's just a symbolic link.  It looks like you have the "modern" style
of zone names, so:

ln -sf /usr/share/zoneinfo/America/New_York /etc/localtime

> use mc to edit the /etc/localtime link?  Surely there is  better way...

I don't know how mc works.  I've never used it.  If that can change the
target of a symlink, similar to running "ln -sf", then you may use it.

> The string as the last few
> bytes of posixrules looks correct at EST5EDT, and I've got a headache.
> there are links to links to links in that midden heap.

I classify time zone names into three historic eras.  In the oldest era,
you have zone names like EST5EDT which are composed of three pieces.
The first piece, EST, is the zone's name when the clock is "normal" (not
daylight saving or summer time).  The second piece, 5, is the number
of hours behind GMT the clock is (normally).  The third piece, EDT, is
the zone's name when daylight saving time is in effect.

In the second era, zone names look like "US/Eastern".  The piece on the
right hand side is a component of the piece on the left.  I'm uncertain
whether the pieces on the left are always country codes, or if there's
some other arrangement.

In the modern era, zone names look like "America/Chicago".  The piece on
the left is a continent (or other large geographic region, e.g. "Pacific"),
and the piece on the right is a major city, preferably *the* major city,
which exemplifies the specific time zone in question.

For you and me, the current era time zone name is "America/New_York".
This is how the Debian installer sets the localtime symlink, and is
what we should be using if we have to set it ourselves.

I personally find "US/Eastern" the easiest to grasp, and I'm sad that
this pattern fell out of fashion, for whatever reason.  Whenever I tell
people on the Internet (who may not be Linux users) what time zone I'm
in, I always go with "US/Eastern".  It's just so *clear*.

Re: ntpsec as server questions

[gene heskett]

On 12/4/23 07:17, Greg Wooledge wrote:


ls -hal /etc/localtime
lrwxrwxrwx 1 root root 27 Nov  1 18:21 /etc/localtime ->
/usr/share/zoneinfo/EST5EDT


And using mc to edit that link fixed it, I am now getting the correct 
time from date, thank you a lot.


But maybe a bug against tzselect s/b filed, IMNSHO it should have fixed 
that. It did not.


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

Re: ntpsec as server questions

[gene heskett]

On 12/4/23 07:17, Greg Wooledge wrote:

ls -hal /etc/localtime


Aha! You found it, but how do I change it?
root@mkspi:/etc# cat timezone
America/New_York
root@mkspi:/etc# ls -hal /etc/localtime
lrwxrwxrwx 1 root root 39 Jul 25  2022 /etc/localtime -> 
/usr/share/zoneinfo/America/Los_Angeles

use mc to edit the /etc/localtime link?  Surely there is  better way...
chasing that link down its a link to ../posixrules, and this dog is 
chasing its own tail, wtf? Something is AFU but what?  The string as the 
last few bytes of posixrules looks correct at EST5EDT, and I've got a 
headache.  there are links to links to links in that midden heap.


Whoever said there lies insanity is correct/

Thanks Greg

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

Re: ntpsec as server questions

[Greg Wooledge]

On Mon, Dec 04, 2023 at 02:11:51PM -0500, gene heskett wrote:
> That leave the localtime error pretty much up to the date command, or is
> there something else screwing with this? Where ALL in this chain does
> /etc/timezone get used, which is currently set to:
> America/New_York

ls -ld /etc/*time*

Please.