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.
