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 OpenPGP: 0x997A9F17ED7DAEA6
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 w
> 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'
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 instea
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
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 var
Greg Wooledge 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
Hi,
29 avr. 2020 à 16:29 de wool...@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 +%
On Wed, Apr 29, 2020 at 08:56:24AM -0500, Martin McCormick wrote:
> Greg Wooledge 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.
Greg Wooledge 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 t
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
Reco 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"
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 comm
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 othe
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
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 argume
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 (
On Tue, 28 Apr 2020 21:45:23 -0400
Roberto C. Sánchez 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 migh
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
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
O
20 matches
Mail list logo
