Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

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

Output from date command defaults to 12-hour in Buster.

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

Contents

  Output from date command defaults to 12-hour in Buster. "Martin McCormick" <martin.m@suddenlink.net> - 2020-04-29 03:40 +0200
    Re: Output from date command defaults to 12-hour in Buster. Roberto C. Sánchez <roberto@debian.org> - 2020-04-29 03:50 +0200
      Re: Output from date command defaults to 12-hour in Buster. Charles Curley <charlescurley@charlescurley.com> - 2020-04-29 07:00 +0200
        Re: Output from date command defaults to 12-hour in Buster. Greg Wooledge <wooledg@eeg.ccf.org> - 2020-04-29 13:50 +0200
          Re: Output from date command defaults to 12-hour in Buster. Nicolas George <george@nsup.org> - 2020-04-29 14:10 +0200
            Re: Output from date command defaults to 12-hour in Buster. Andrei POPESCU <andreimpopescu@gmail.com> - 2020-04-29 19:10 +0200
              Re: Output from date command defaults to 12-hour in Buster. Nicolas George <george@nsup.org> - 2020-04-29 19:20 +0200
                Re: Output from date command defaults to 12-hour in Buster. Andrei POPESCU <andreimpopescu@gmail.com> - 2020-04-30 10:30 +0200
                  Re: Output from date command defaults to 12-hour in Buster. Greg Wooledge <wooledg@eeg.ccf.org> - 2020-04-30 13:20 +0200
                    Re: Output from date command defaults to 12-hour in Buster. Nicolas George <george@nsup.org> - 2020-04-30 17:10 +0200
          Re: Output from date command defaults to 12-hour in Buster. "Martin McCormick" <martin.m@suddenlink.net> - 2020-04-29 16:00 +0200
            Re: Output from date command defaults to 12-hour in Buster. Greg Wooledge <wooledg@eeg.ccf.org> - 2020-04-29 16:30 +0200
              Re: Output from date command defaults to 12-hour in Buster. l0f4r0@tuta.io - 2020-04-29 18:20 +0200
    Re: Output from date command defaults to 12-hour in Buster. Reco <recoverym4n@enotuniq.net> - 2020-04-29 08:20 +0200
      Re: Output from date command defaults to 12-hour in Buster. Greg Wooledge <wooledg@eeg.ccf.org> - 2020-04-29 14:10 +0200
        Re: Output from date command defaults to 12-hour in Buster. Nicolas George <george@nsup.org> - 2020-04-29 14:20 +0200
      Re: Output from date command defaults to 12-hour in Buster. Greg Wooledge <wooledg@eeg.ccf.org> - 2020-04-29 15:10 +0200
        Re: Output from date command defaults to 12-hour in Buster. "Martin McCormick" <martin.m@suddenlink.net> - 2020-04-29 18:30 +0200
      Re: Output from date command defaults to 12-hour in Buster. "Martin McCormick" <martin.m@suddenlink.net> - 2020-04-29 15:10 +0200
    Re: Output from date command defaults to 12-hour in Buster. James Cloos <cloos@jhcloos.com> - 2020-05-01 18:30 +0200

#222066 — Output from date command defaults to 12-hour in Buster.

In every flavor of unix I have used since I began learning unix
in 1989, the date command would produce a string containing the
current time in 24-hour format
similar to

Tue Apr 28 20:25:11 CDT 2020

	If you run the date command in buster, you get

Tue 28 Apr 2020 08:26:24 PM CDT

	One can cause date to run in 24-hour format but you have
to run date as follows:

date +"%a %b %d %T %Z %Y"

	Some people have set their locale to British English and
now get the older-style 24-hour date format but setting the
locale is kind of an extreme way to do things.

	Is there any environment variable or local configuration
variable which will make date produce the 24-hour time stamp
similar to past implementations of date?

Martin McCormick

[toc] | [next] | [standalone]

#222067

On Tue, Apr 28, 2020 at 08:36:11PM -0500, Martin McCormick wrote:
> In every flavor of unix I have used since I began learning unix
> in 1989, the date command would produce a string containing the
> current time in 24-hour format
> similar to
> 
> Tue Apr 28 20:25:11 CDT 2020
> 
> 	If you run the date command in buster, you get
> 
> Tue 28 Apr 2020 08:26:24 PM CDT
> 
> 	One can cause date to run in 24-hour format but you have
> to run date as follows:
> 
> date +"%a %b %d %T %Z %Y"
> 
> 	Some people have set their locale to British English and
> now get the older-style 24-hour date format but setting the
> locale is kind of an extreme way to do things.
> 
> 	Is there any environment variable or local configuration
> variable which will make date produce the 24-hour time stamp
> similar to past implementations of date?
> 

You probably have LANG set, but it seems you might already know that.

roberto@miami:~$ echo $LANG
en_US.utf8
roberto@miami:~$ date
Tue 28 Apr 2020 09:41:33 PM EDT
roberto@miami:~$ LC_TIME=C date
Tue Apr 28 21:41:37 EDT 2020

Since the convention in the US is to use AM/PM, it stands to reason that
setting the locale will produce a conventional date format for the
locale.  Note the folling from the locale(7) man page:

       LC_TIME
              This category governs the formatting used for date and
              time values.  For example, most of Europe uses a 24-hour
              clock versus the 12-hour clock used in the United States.
              The setting of this category affects the behavior of
              functions such as strftime(3) and strptime(3).

Regards,

-Roberto

-- 
Roberto C. Sánchez

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

#222070

On Tue, 28 Apr 2020 21:45:23 -0400
Roberto C. Sánchez <roberto@debian.org> wrote:

> > 	Is there any environment variable or local configuration
> > variable which will make date produce the 24-hour time stamp
> > similar to past implementations of date?
> >   
> 
> You probably have LANG set, but it seems you might already know that.

Which may be true, but doesn't answer the gentleman's question.

Adding

alias date='date +"%a %b %d %T %Z %Y"'

to one's .bashrc or /etc/bashrc should get the OP what he wants.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

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

#222078

On Tue, Apr 28, 2020 at 10:53:25PM -0600, Charles Curley wrote:
> Adding
> 
> alias date='date +"%a %b %d %T %Z %Y"'
> 
> to one's .bashrc or /etc/bashrc should get the OP what he wants.

No, this is not a viable solution.  It will completely hinder your
ability to use date with other format arguments, and it will not
address the underlying problem, which is in the locale definition used
by strftime(3) and similar pieces of libc.  (There are other programs
that are affected by this, not just date(1).)

Setting LC_TIME=C is a much better answer.


unicorn:~$ locale | grep -v \"$
LANG=en_US.utf8
LANGUAGE=
LC_ALL=
unicorn:~$ date
Wed 29 Apr 2020 07:43:23 AM EDT
unicorn:~$ export LC_TIME=C
unicorn:~$ date
Wed Apr 29 07:44:00 EDT 2020


unicorn:~$ unset LC_TIME
unicorn:~$ printf '%()T\n' -1
07:45:12 AM
unicorn:~$ export LC_TIME=C
unicorn:~$ printf '%()T\n' -1
07:45:31


And so on.

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

#222080

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

Greg Wooledge (12020-04-29):
> No, this is not a viable solution.  It will completely hinder your
> ability to use date with other format arguments, and it will not
> address the underlying problem, which is in the locale definition used
> by strftime(3) and similar pieces of libc.  (There are other programs
> that are affected by this, not just date(1).)

Very well said.

> Setting LC_TIME=C is a much better answer.

Not setting LANG is an even better answer.

Seriously, except for LC_CTYPE, which would be better be encoded as part
of the TERM variable, and LC_MESSAGES when the translations happen to be
half decent, all locales category are some variant of
LB_BREAK_SOMETHING.

More than 20 years ago, if you were to build on Objective Caml
interpreter with Gtk+ libraries, then "let pi = 3.14;;" would cause pi
to be equal to 3.0, just because of LC_BREAK_SOMETHING.

If you want a system that works, set LC_CTYPE, and leave everything else
alone.

Regards,

-- 
  Nicolas George

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

#222103

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

On Mi, 29 apr 20, 14:03:42, Nicolas George wrote:
> 
> Not setting LANG is an even better answer.
> 
> Seriously, except for LC_CTYPE, which would be better be encoded as part
> of the TERM variable, and LC_MESSAGES when the translations happen to be
> half decent, all locales category are some variant of
> LB_BREAK_SOMETHING.

Could you please kindly elaborate on this for the rest of the world 
where LANG is not some variant of en_XX ?

Thanks,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

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

#222106

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

Andrei POPESCU (12020-04-29):
> Could you please kindly elaborate on this for the rest of the world 
> where LANG is not some variant of en_XX ?

I live in the rest of the world, and I do NOT want my numbers to have
commas in them instead of decimal points, nor do I want [0-9a-f] to
match "ça" and "fée". Do you?

Regards,

-- 
  Nicolas George

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

#222142

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

On Mi, 29 apr 20, 19:18:14, Nicolas George wrote:
> Andrei POPESCU (12020-04-29):
> > Could you please kindly elaborate on this for the rest of the world 
> > where LANG is not some variant of en_XX ?
> 
> I live in the rest of the world, and I do NOT want my numbers to have
> commas in them instead of decimal points, nor do I want [0-9a-f] to
> match "ça" and "fée". Do you?

Actually I do. Now what?

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

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

#222144

> On Mi, 29 apr 20, 19:18:14, Nicolas George wrote:
> > I live in the rest of the world, and I do NOT want my numbers to have
> > commas in them instead of decimal points, nor do I want [0-9a-f] to
> > match "ça" and "fée".

For the first part, you want LC_NUMERIC=C.

For the second part, what you're asking for is sometimes called
"rational ranges", or "rational range interpretation".  This is the
notion that, for specific range expressions like '[a-z]' within a
regular expression or glob, the software will assume you want to
match only '[[:lower:]]', rather than doing what you actually said.

The idea behind this is based on the (probably accurate) belief that
most people who write [a-z] or [A-Z] in their scripts wanted the
LC_COLLATE=C (or 1980s) meaning of the range, not the meaning of the
range in modern times.  Thus, it's a sort of safety net strung below
the novice programmer, to catch them when they fall.

Since this is not how systems currently behave, however, what you need
to do in your script is write the expression correctly.  For your
example, I believe that would be [[:xdigit:]].  Or if you really do
mean to restrict it to lower-case 'a' through 'f', retain what you
have, but set LC_COLLATE=C first.

I haven't seen rational range interpretation discussion that covers
'[a-f]', but I haven't been following it closely.

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

#222148

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

Greg Wooledge (12020-04-30):
> For the first part, you want LC_NUMERIC=C.

Damn right I want LC_NUMERIC=C. And I want LC_COLLATE=C. And I want
LC_NUMERIC=C, and LC_TIME=C.

And I also want LC_WHATEVER_THE_HECK_THEY_WILL_INVENT_NEXT=C too. I want
LC_EVERYTHING=C except LC_CTYPE.

And everybody who works with command-line tools should want the same,
because these things were ugly mistakes with way more drawbacks than
benefits.

> For the second part, what you're asking for is sometimes called
> "rational ranges", or "rational range interpretation".  This is the
> notion that, for specific range expressions like '[a-z]' within a
> regular expression or glob, the software will assume you want to
> match only '[[:lower:]]', rather than doing what you actually said.
> 
> The idea behind this is based on the (probably accurate) belief that
> most people who write [a-z] or [A-Z] in their scripts wanted the
> LC_COLLATE=C (or 1980s) meaning of the range, not the meaning of the
> range in modern times.  Thus, it's a sort of safety net strung below
> the novice programmer, to catch them when they fall.
> 
> Since this is not how systems currently behave, however, what you need
> to do in your script is write the expression correctly.  For your
> example, I believe that would be [[:xdigit:]].  Or if you really do
> mean to restrict it to lower-case 'a' through 'f', retain what you
> have, but set LC_COLLATE=C first.
> 
> I haven't seen rational range interpretation discussion that covers
> '[a-f]', but I haven't been following it closely.

I am very aware of the pros of cons of localized collation. The thing
that was incredibly stupid was to change the semantic of something as
fundamental as regular expressions. The correct way to introduce
localized alphabetical order in regular expression would have been to
introduce a new notation for it, not to hijack something that was
already used.

Since this ugly mistake has been made, the only sane course of action is
to let locales to their C setting. Which is exactly what I do, and I am
very fine with it.

And I can laugh by myself every time somebody comes complaining that the
output of a command is ugly because it did not consider localization
would break alignment, or that a script is broken because the matching
of a regexp has been altered.

Regards,

-- 
  Nicolas George

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

#222087

Greg Wooledge <wooledg@eeg.ccf.org> writes:
> On Tue, Apr 28, 2020 at 10:53:25PM -0600, Charles Curley wrote:
> > Adding
> >
> > alias date='date +"%a %b %d %T %Z %Y"'
> >
> > to one's .bashrc or /etc/bashrc should get the OP what he wants.

	It did make just the date command work as desired.  I
actually tried that very thing maybe a year or so ago
and it worked, sort of.

Greg Wooledge continues:

> No, this is not a viable solution.  It will completely hinder your
> ability to use date with other format arguments, and it will not
> address the underlying problem, which is in the locale definition used
> by strftime(3) and similar pieces of libc.  (There are other programs
> that are affected by this, not just date(1).)
> 
> Setting LC_TIME=C is a much better answer.

	I do appreciate the help.  I remember setting up the
alias, cheering when the date command worked, and then about 10
or 15 seconds later, swearing when something else, I forget what,
filled the screen with a cacophony of error messages and I
immediately realized why and put things back the way they had
been.

Martin

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

#222090

On Wed, Apr 29, 2020 at 08:56:24AM -0500, Martin McCormick wrote:
> Greg Wooledge <wooledg@eeg.ccf.org> writes:
> > On Tue, Apr 28, 2020 at 10:53:25PM -0600, Charles Curley wrote:
> > > Adding
> > >
> > > alias date='date +"%a %b %d %T %Z %Y"'
> > >
> > > to one's .bashrc or /etc/bashrc should get the OP what he wants.
> 
> 	It did make just the date command work as desired.  I
> actually tried that very thing maybe a year or so ago
> and it worked, sort of.

It breaks if you try to use your own "plus" argument.

unicorn:~$ alias date='date +"%a %b %d %T %Z %Y"'
unicorn:~$ date +%s
date: extra operand ‘+%s’
Try 'date --help' for more information.
unicorn:~$ unalias date
unicorn:~$ date +%s
1588170499

If you mean "It worked when I ran date with no arguments", then sure,
it will "work" for that one sample case.  But it breaks in many other
cases.

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

#222095

Hi,

29 avr. 2020 à 16:29 de wooledg@eeg.ccf.org:

> It breaks if you try to use your own "plus" argument.
>
> unicorn:~$ alias date='date +"%a %b %d %T %Z %Y"'
> unicorn:~$ date +%s
> date: extra operand ‘+%s’
> Try 'date --help' for more information.
> unicorn:~$ unalias date
> unicorn:~$ date +%s
> 1588170499
>
> If you mean "It worked when I ran date with no arguments", then sure,
> it will "work" for that one sample case.  But it breaks in many other
> cases.
>
Maybe you will find more appropriate use cases but for this one, there is a simple workaround:

$ date +"%a %b %d %T %Z %Y" 
Wed Apr 29 18:02:14 CEST 2020
$ date +"%s"
1588176139
$ alias date='date +"%a %b %d %T %Z %Y"'
$ date
Wed Apr 29 18:02:32 CEST 2020
$ \date +"%s"
1588176170

Best regards,
l0f4r0

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

#222072

	Hi.

On Tue, Apr 28, 2020 at 08:36:11PM -0500, Martin McCormick wrote:
> 	Is there any environment variable or local configuration
> variable which will make date produce the 24-hour time stamp
> similar to past implementations of date?

If you need it systemwide, consider doing this (will require relogin, at
least):

echo 'LC_TIME=C' >> /etc/default/locale

If you need it for your user only (will require a new terminal emulator), 

echo 'LC_TIME=C' >> ~/.bashrc

Reco

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

#222079

On Wed, Apr 29, 2020 at 09:11:05AM +0300, Reco wrote:
> If you need it systemwide, consider doing this (will require relogin, at
> least):
> 
> echo 'LC_TIME=C' >> /etc/default/locale

I do not recommend hard-coding locales system-wide.  Individual users
should be free to set their own environments.

> If you need it for your user only (will require a new terminal emulator), 
> 
> echo 'LC_TIME=C' >> ~/.bashrc

You'll need to export it, in order for it have any effect on external
commands (like date).

The choice of .bashrc may be fine for GNOME users (hell, it may even be
*mandatory* for GNOME users, because GNOME is user-unfriendly shit),
but even then, it only affects commands that are launched from an
interactive shell.

In order to take effect in commands that are launched by the window
manager, or whatever, environment changes should be done much earlier
in the session.

For shell logins, you would want to put the command(s) in ~/.profile or
whatever your login shell's equivalent dot file is.

For GUI logins that are not GNOME, you can try setting up the environment
in ~/.xsessionrc -- but note that your Desktop Environment (even if it's
not GNOME) may overwrite whatever you try to set.

If it's GNOME, well, you're screwed.  GNOME has its own idea of how to
set up the user's locale, and it does not include such subtle concepts as
"use one locale for most things, but fine-tune LC_COLLATE and LC_TIME".
This has come up in the past on this mailing list, and there is no known
solution to it (other than "don't use GNOME").


The last time the "date in buster" issue came up, I experimented with
a customized locale -- see my write-up at
<https://www.mail-archive.com/debian-user@lists.debian.org/msg741047.html>
or whatever list archive Google happens to choose for you.

Since that time, I abandoned that approach.  It's too clunky in real
life -- too much trouble, too many opportunities for something to go
wrong, e.g. the environment variable doesn't get set where it needs
to be set, or *does* get set where it shouldn't, like inside a chroot
or similar encapsulation.

I just went with the LC_TIME=C approach instead.

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

#222081

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

Greg Wooledge (12020-04-29):
> The choice of .bashrc may be fine for GNOME users (hell, it may even be
> *mandatory* for GNOME users, because GNOME is user-unfriendly shit),
> but even then, it only affects commands that are launched from an
> interactive shell.
> 
> In order to take effect in commands that are launched by the window
> manager, or whatever, environment changes should be done much earlier
> in the session.
> 
> For shell logins, you would want to put the command(s) in ~/.profile or
> whatever your login shell's equivalent dot file is.
> 
> For GUI logins that are not GNOME, you can try setting up the environment
> in ~/.xsessionrc -- but note that your Desktop Environment (even if it's
> not GNOME) may overwrite whatever you try to set.

With a smarter shell than bash, there is a solution that works for all
these cases, and even a few others: ~/.zshenv will be called for all zsh
instances (and therefore needs to be very minimalistic, and preferably
set up to avoid overwriting explicit changes).

So it will take effect for login shell on a VC, remote login shell,
remote non-login shell (to set $PATH so that rsync finds
~/local/bin/rsync), programs launched by the WM if it uses $SHELL, even
GUI sessions if ~/.xsessionrc is #!/bin/zsh.

Mine starts with:

[[ "$ZSHENV_USER" == $UID-1 ]] && return
export ZSHENV_USER=$UID-1

And then it sets the environment up. Bonus point: if I change the 1 into
2, it even takes effect on all new shells, no need to re-log.

Regards,

-- 
  Nicolas George

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

#222084

On Wed, Apr 29, 2020 at 08:00:05AM -0500, Martin McCormick wrote:
> 	I had thought all along that I was dealing with a feature
> rather than a bug

It's an intentional change.  It's a "feature" from the libc developers'
point of view.  As far as they are concerned, Americans use 12-hour
clocks, so the en_US.utf8 locale is supposed to present times in 12-hour
format by default.

The fact that many of us *don't* want times shown in that format is a
preference, so it falls on us to configure our own environments according
to our own tastes.

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

#222096

Greg Wooledge <wooledg@eeg.ccf.org> writes:
> It's an intentional change.  It's a "feature" from the libc developers'
> point of view.  As far as they are concerned, Americans use 12-hour
> clocks, so the en_US.utf8 locale is supposed to present times in 12-hour
> format by default.

	This American is an amateur radio operator and before
that was a short wave listener since the age of around eleven and
grew to like the 24-hour clock since any given time occurs
exactly once per day.

	One day, at work several years ago, I saw an outage
announcement for one of our departments for a service and started
to heat up under the collar because the outage was going to be
between 11:00 and 12:30 or something like that but the thermal
rise around the neck line soon cooled when I realized that it was
PM and AM so nothing terrible was about to happen as this would
have been cause for mutiny if it was the middle of the day.
> 
> The fact that many of us *don't* want times shown in that format is a
> preference, so it falls on us to configure our own environments according
> to our own tastes.

	That's fine now that I know what is really happening and
everybody can go home happy.

	I remember grousing to a coworker of mine as to when
would we start telling time like grownups around here,bla,bla,bla
and her response was,

"If you think we're going to start using military time, it's
never going to happen.

	She, by the way, wasn't involved with the outage so we
were just having a conversation and I was glad I caught the AM
and PM parts before making a fool of myself which is easily done.

Martin

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

#222085

Reco <recoverym4n@enotuniq.net> writes:
>         Hi.

> If you need it systemwide, consider doing this (will require relogin, at
> least):
> echo 'LC_TIME=C' >> /etc/default/locale

That was what I needed.  /etc/default/locale did not contain that
line but did contain 

#  File generated by update-locale
LANG="en_US.UTF-8"
> 
> If you need it for your user only (will require a new terminal emulator),
> 
> echo 'LC_TIME=C' >> ~/.bashrc


	Many thanks to all who responded.

	I had thought all along that I was dealing with a feature
rather than a bug because one of the beautiful things about the
philosophy of unix-like operating systems is that new
capabilities tend to layer on top of older behaviors so one can
enjoy the best of all worlds when it is practical and safe to
have this capability.

	My first thought after making the change was that it had
had no effect but I was not completely logging out.  I run the
screen utility and so I stopped screen but was still logged in.
After getting down to the login prompt, logging in with the usual
username and password, not only did this installation work but I
happen to be running 2 other installations of buster on  other
old PC's and since the environment variable is exported with each
new screen window, their responses to the date command magically fixed
themselves.

Martin

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

#222170

The easiest fix is to:

export LC_TIME=C

just like one must export LC_COLLATE=C to avoid glibc's brkoen collation
for en_US.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web