[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ntpsec as server questions



On Tue, Dec 05, 2023 at 12:01:35AM +0700, Max Nikulin wrote:
> On 04/12/2023 23:34, Greg Wooledge wrote:
> > > 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.
> 
>     dpkg-reconfigure locales
> 
> Or its equivalent for modified armbian. See /etc/default/locale and
> https://www.debian.org/doc/manuals/debian-reference/ch09.en.html#_customized_display_of_time_and_date

That chapter talks about customizing timestamps in "ls -l" output.

> "9.3.4. Customized display of time and date" and "9.5.5. System and hardware
> time".

Chapter 9.5.5 talks about setting the hardware clock, and recommends
installing an NTP package.

Neither of these chapters tells you how to make the "date" command give
you the output format you want.  At least not directly.  A clever user
might extrapolate from the "ls -l" and "alias" examples that they could
create an alias for "date" which would pass a customized + argument
for a customized output format.  And that's certainly possible, but isn't
something I'd choose to do.  Most importantly because it would only affect
the "date" command typed in an interactive shell; it wouldn't affect
date(1) run by scripts, or anything else which uses the %c format
operator in strftime(3).

If you want to get rid of the 12-hour time format by *default* (%c),
then neither of these chapters actually helps you.  What you want to do
is override the LC_TIME variable.

unicorn:~$ (unset LC_TIME; date)
Mon Dec  4 01:32:29 PM EST 2023
unicorn:~$ LC_TIME=C date
Mon Dec  4 13:32:33 EST 2023

On my system (Debian 12), the default LC_TIME format in the en_US.utf8
locale is that 12-hour thing.  I have "export LC_TIME=C" in my shell's
dot files, so that I get the traditional 24-hour output instead.

This affects all uses of strftime's %c, including bash's builtin printf:

unicorn:~$ printf '%(%c)T\n'
Mon Dec  4 13:34:35 2023
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 hope, no applications rely on specific locale while parsing time or
> numbers.

I would not care to wager on that.

>     echo "$TZ"

This is almost always unset.  Normal users don't tend to set this.  It's
just not part of the public consciousness, for whatever reason.

The *vastly* overwhelming majority of users rely on their system's default
time zone instead.

> https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html
> but ignore most of its content, use zone identifiers like America/New_York

Or whatever is in your system's /usr/share/zoneinfo/ or wherever your
system's /etc/localtime symlink points.

WE ARE STILL WAITING TO SEE WHERE GENE'S /etc/localtime POINTS.
Hint, hint.


Reply to: