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

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

How to set ISO date/time with en_US.utf8 as system default?

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

Contents

  How to set ISO date/time with en_US.utf8 as system default? gwmfms6@openmailbox.org - 2017-05-26 17:40 +0200
    Re: How to set ISO date/time with en_US.utf8 as system default? Greg Wooledge <wooledg@eeg.ccf.org> - 2017-05-26 17:50 +0200
      Re: How to set ISO date/time with en_US.utf8 as system default? Greg Wooledge <wooledg@eeg.ccf.org> - 2017-05-26 18:10 +0200
        Re: How to set ISO date/time with en_US.utf8 as system default? gwmfms6@openmailbox.org - 2017-05-26 18:40 +0200
          Re: How to set ISO date/time with en_US.utf8 as system default? Greg Wooledge <wooledg@eeg.ccf.org> - 2017-05-26 18:50 +0200
            Re: How to set ISO date/time with en_US.utf8 as system default? gwmfms6@openmailbox.org - 2017-05-26 19:00 +0200
              Re: How to set ISO date/time with en_US.utf8 as system default? Greg Wooledge <wooledg@eeg.ccf.org> - 2017-05-26 19:10 +0200
                Re: How to set ISO date/time with en_US.utf8 as system default? Curt <curty@free.fr> - 2017-05-27 12:20 +0200
                  Re: How to set ISO date/time with en_US.utf8 as system default? gwmfms6@openmailbox.org - 2017-05-27 14:40 +0200
                    Re: How to set ISO date/time with en_US.utf8 as system default? Curt <curty@free.fr> - 2017-05-27 16:30 +0200
                      Re: How to set ISO date/time with en_US.utf8 as system default? gwmfms6@openmailbox.org - 2017-05-27 17:20 +0200
                        Re: How to set ISO date/time with en_US.utf8 as system default? Curt <curty@free.fr> - 2017-05-27 17:40 +0200
                          Re: How to set ISO date/time with en_US.utf8 as system default? rhkramer@gmail.com - 2017-05-27 20:10 +0200
                          Re: How to set ISO date/time with en_US.utf8 as system default? Curt <curty@free.fr> - 2017-05-27 22:00 +0200
                    Re: How to set ISO date/time with en_US.utf8 as system default? Frank <zuiderduin@gmx.com> - 2017-05-27 17:00 +0200
                      Re: How to set ISO date/time with en_US.utf8 as system default? gwmfms6@openmailbox.org - 2017-05-27 17:30 +0200
                        Re: How to set ISO date/time with en_US.utf8 as system default? Jeremy Nicoll <jn.ml.dbn.25@letterboxes.org> - 2017-05-27 17:50 +0200
                        Re: How to set ISO date/time with en_US.utf8 as system default? Nicolas George <george@nsup.org> - 2017-05-27 17:50 +0200
                          Re: How to set ISO date/time with en_US.utf8 as system default? gwmfms6@openmailbox.org - 2017-05-27 18:10 +0200
                          Re: How to set ISO date/time with en_US.utf8 as system default? David Wright <deblis@lionunicorn.co.uk> - 2017-05-28 03:50 +0200
                    Re: How to set ISO date/time with en_US.utf8 as system default? Greg Wooledge <wooledg@eeg.ccf.org> - 2017-05-30 14:50 +0200
                      Re: How to set ISO date/time with en_US.utf8 as system default? gwmfms6@openmailbox.org - 2017-05-30 18:30 +0200
                        RE: How to set ISO date/time with en_US.utf8 as system default? "Emanuele Bernardi" <e.berna@posteo.net> - 2017-05-30 18:50 +0200
                          RE: How to set ISO date/time with en_US.utf8 as system default? gwmfms6@openmailbox.org - 2017-05-31 16:10 +0200
            Re: How to set ISO date/time with en_US.utf8 as system default? gwmfms6@openmailbox.org - 2017-05-26 19:00 +0200
              Re: How to set ISO date/time with en_US.utf8 as system default? Greg Wooledge <wooledg@eeg.ccf.org> - 2017-05-26 19:10 +0200
                Re: How to set ISO date/time with en_US.utf8 as system default? gwmfms6@openmailbox.org - 2017-05-26 19:10 +0200
                  Re: How to set ISO date/time with en_US.utf8 as system default? James Cloos <cloos@jhcloos.com> - 2017-05-27 20:50 +0200

Page 1 of 2  [1] 2  Next page →

#181419 — How to set ISO date/time with en_US.utf8 as system default?

This wiki is apparently out of date because it does not work: 
https://wiki.debian.org/Locale#First_day_of_week

I have the system default set to en_US.utf8. But I need sensical dates 
and times (and en_US.utf8 uses nonsensical date & time format).

How can I set my Debian 8 stable to use en_DK.utf8 for LC_TIME and 
LC_MEASUREMENT variables while keeping en_US.utf8 the system default for 
everything else?

[toc] | [next] | [standalone]

#181420

On Fri, May 26, 2017 at 11:30:15AM -0400, gwmfms6@openmailbox.org wrote:
> This wiki is apparently out of date because it does not work:
> https://wiki.debian.org/Locale#First_day_of_week

I don't advise putting ANYTHING at all in /etc/default/locale.  That
would affect all logins by all users from all computers.  But supposing
either (1) that's actually what you want, or (2) you're going to set
your variables in your personal login configuration instead....

> I have the system default set to en_US.utf8. But I need sensical dates
> and times (and en_US.utf8 uses nonsensical date & time format).
>
> How can I set my Debian 8 stable to use en_DK.utf8 for LC_TIME and
> LC_MEASUREMENT variables while keeping en_US.utf8 the system default for
> everything else?

1) Make sure both locales have actually been generated, via

   dpkg-reconfigure locales

2) Verify they they are both available:

   titan:~$ locale -a
   C
   C.UTF-8
   en_DK.utf8
   en_US.utf8
   POSIX

3) Set the variables:

   titan:~$ export LANG=en_US.utf8 LC_TIME=en_DK.utf8 LC_MEASUREMENT=en_DK.utf8

   (If you want this to be permanent, figure out what dot files to put
   them in.  That's the hardest part of all.)

4) Test:

   titan:~$ ncal
       May 2017
   Mo  1  8 15 22 29
   Tu  2  9 16 23 30
   We  3 10 17 24 31
   Th  4 11 18 25
   Fr  5 12 19 26
   Sa  6 13 20 27
   Su  7 14 21 28

   titan:~$ unset LC_TIME LC_MEASUREMENT
   titan:~$ ncal
       May 2017
   Su     7 14 21 28
   Mo  1  8 15 22 29
   Tu  2  9 16 23 30
   We  3 10 17 24 31
   Th  4 11 18 25
   Fr  5 12 19 26
   Sa  6 13 20 27

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

#181421

On Fri, May 26, 2017 at 11:54:14AM -0400, gwmfms6@openmailbox.org wrote:
> Thank you.

You forgot to include the mailing list.

> I have already done #1 and #2.

Did it work?

> #3 is what I need

Did it work?

> but I want them permanent. I am fine with it being 
> system-wide for every login (ie, /etc/default/locale but as I said 
> putting them doesn't work). I will also go to the trouble of configuring 
> for each user if this is the only way to make these variables 
> "permanent." How do I make these settings permanent?

If you actually did put them in /etc/default/locale then I am confused
about what you're asking, or what's actually wrong.  PAM logins in jessie
(sshd, console login) are configured by default to read environment
variables from /etc/default/locale via the /etc/pam.d/* files that contain
"pam_env.so readenv=1 envfile=/etc/default/locale" or similar.

If you log out and back in, and run "locale" with no arguments, what does
it say?

Is it possible that your desktop environment is overwriting whatever
PAM sets in the environment?  Try testing via a console or ssh login,
and see if it's different there.  (E.g. "ssh localhost" and then run
"locale".)  If you get a different result from this, that would be
*highly* significant.

What desktop environment or window manager are you actually using?
How are you logging in?  (Console + startx, or lightdm, or gdm3, or
some other display manager....)

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

#181422

I did #1 and #2 before posting here, before putting LC_TIME at 
/etc/default/locale. I reconfirmed that it is as you say it should be 
when running locale -a.

Here is what locale reports after I log back in:
~/Desktop $ locale
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=en_US.utf8
LC_TIME=en_US.utf8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=en_US.utf8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=en_US.utf8
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT=en_US.utf8
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=


Here is what my /etc/default/locale looks like:
~/Desktop $ cat /etc/default/locale
LANG=en_US.UTF-8
LC_TIME=en_DK.UTF-8


As you can see LC_TIME is set to en_DK in /etc/default/locale but locale 
is not reporting this when it is run.
I did #1 and #2 before posting here, before putting LC_TIME at 
/etc/default/locale. I reconfirmed that it is as you say it should be 
when running locale -a.

Here is what locale reports after I log back in:
~/Desktop $ locale
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=en_US.utf8
LC_TIME=en_US.utf8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=en_US.utf8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=en_US.utf8
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT=en_US.utf8
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=


Here is what my /etc/default/locale looks like:
~/Desktop $ cat /etc/default/locale
LANG=en_US.UTF-8
LC_TIME=en_DK.UTF-8


As you can see LC_TIME is set to en_DK in /etc/default/locale but locale 
is not reporting this when it is run.

I did #1 and #2 before posting here, before putting LC_TIME at 
/etc/default/locale. I reconfirmed that it is as you say it should be 
when running locale -a.

Here is what locale reports after I log back in:
~/Desktop $ locale
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=en_US.utf8
LC_TIME=en_US.utf8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=en_US.utf8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=en_US.utf8
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT=en_US.utf8
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=


Here is what my /etc/default/locale looks like:
~/Desktop $ cat /etc/default/locale
LANG=en_US.UTF-8
LC_TIME=en_DK.UTF-8


As you can see LC_TIME is set to en_DK in /etc/default/locale but locale 
is not reporting this when it is run.




On 2017-05-26 18:05, Greg Wooledge wrote:
> On Fri, May 26, 2017 at 11:54:14AM -0400, gwmfms6@openmailbox.org 
> wrote:
>> Thank you.
> 
> You forgot to include the mailing list.
> 
>> I have already done #1 and #2.
> 
> Did it work?
> 
>> #3 is what I need
> 
> Did it work?
> 
>> but I want them permanent. I am fine with it being
>> system-wide for every login (ie, /etc/default/locale but as I said
>> putting them doesn't work). I will also go to the trouble of 
>> configuring
>> for each user if this is the only way to make these variables
>> "permanent." How do I make these settings permanent?
> 
> If you actually did put them in /etc/default/locale then I am confused
> about what you're asking, or what's actually wrong.  PAM logins in 
> jessie
> (sshd, console login) are configured by default to read environment
> variables from /etc/default/locale via the /etc/pam.d/* files that 
> contain
> "pam_env.so readenv=1 envfile=/etc/default/locale" or similar.
> 
> If you log out and back in, and run "locale" with no arguments, what 
> does
> it say?
> 
> Is it possible that your desktop environment is overwriting whatever
> PAM sets in the environment?  Try testing via a console or ssh login,
> and see if it's different there.  (E.g. "ssh localhost" and then run
> "locale".)  If you get a different result from this, that would be
> *highly* significant.
> 
> What desktop environment or window manager are you actually using?
> How are you logging in?  (Console + startx, or lightdm, or gdm3, or
> some other display manager....)

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

#181423

On Fri, May 26, 2017 at 06:31:29PM +0200, gwmfms6@openmailbox.org wrote:
> ~/Desktop $ cat /etc/default/locale
> LANG=en_US.UTF-8
> LC_TIME=en_DK.UTF-8

> ~/Desktop $ locale
> LANG=en_US.UTF-8
> LANGUAGE=
> LC_CTYPE="en_US.UTF-8"
> LC_NUMERIC=en_US.utf8
> LC_TIME=en_US.utf8
> LC_COLLATE="en_US.UTF-8"
> LC_MONETARY=en_US.utf8
> LC_MESSAGES="en_US.UTF-8"
> LC_PAPER=en_US.utf8
> LC_NAME="en_US.UTF-8"
> LC_ADDRESS="en_US.UTF-8"
> LC_TELEPHONE="en_US.UTF-8"
> LC_MEASUREMENT=en_US.utf8
> LC_IDENTIFICATION="en_US.UTF-8"
> LC_ALL=

> As you can see LC_TIME is set to en_DK in /etc/default/locale but locale 
> is not reporting this when it is run.

Does this change if you login on a text console?

Does this change if you login via "ssh localhost" (or "ssh $HOSTNAME",
or ssh in from a different host to this one over a network)?

What desktop environment are you using?  What display manager are you
using to login?

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

#181424

A virtual console (eg, Ctrl+Alt+F2) produces the correct result when I 
type ncal.

But if I type ncal in gnome-terminal, it starts the weeks with Sunday 
(which is wrong). GNOME problem, right? That's why /etc/default/locale 
isn't working how I expected?

On 2017-05-26 12:54, gwmfms6@openmailbox.org wrote:
> I neglected to say my environment. Sorry! I am on GNOME and login via 
> GDM.
> 
> I do not use SSH and it says connection refused when I try.
> 
> when I open a virtual console, and type ncal, the calendar begins with
> Monday--so this appears to be working.
> 
> The problem is with GNOME, then? I suppose Debian can't help with that?
> 
> On 2017-05-26 12:48, Greg Wooledge wrote:
>> On Fri, May 26, 2017 at 06:31:29PM +0200, gwmfms6@openmailbox.org 
>> wrote:
>>> ~/Desktop $ cat /etc/default/locale
>>> LANG=en_US.UTF-8
>>> LC_TIME=en_DK.UTF-8
>> 
>>> ~/Desktop $ locale
>>> LANG=en_US.UTF-8
>>> LANGUAGE=
>>> LC_CTYPE="en_US.UTF-8"
>>> LC_NUMERIC=en_US.utf8
>>> LC_TIME=en_US.utf8
>>> LC_COLLATE="en_US.UTF-8"
>>> LC_MONETARY=en_US.utf8
>>> LC_MESSAGES="en_US.UTF-8"
>>> LC_PAPER=en_US.utf8
>>> LC_NAME="en_US.UTF-8"
>>> LC_ADDRESS="en_US.UTF-8"
>>> LC_TELEPHONE="en_US.UTF-8"
>>> LC_MEASUREMENT=en_US.utf8
>>> LC_IDENTIFICATION="en_US.UTF-8"
>>> LC_ALL=
>> 
>>> As you can see LC_TIME is set to en_DK in /etc/default/locale but 
>>> locale
>>> is not reporting this when it is run.
>> 
>> Does this change if you login on a text console?
>> 
>> Does this change if you login via "ssh localhost" (or "ssh $HOSTNAME",
>> or ssh in from a different host to this one over a network)?
>> 
>> What desktop environment are you using?  What display manager are you
>> using to login?

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

#181426

On Fri, May 26, 2017 at 12:57:22PM -0400, gwmfms6@openmailbox.org wrote:
> A virtual console (eg, Ctrl+Alt+F2) produces the correct result when I 
> type ncal.
> 
> But if I type ncal in gnome-terminal, it starts the weeks with Sunday 
> (which is wrong). GNOME problem, right? That's why /etc/default/locale 
> isn't working how I expected?

Yes, sounds like it.

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

#181485

On 2017-05-26, Greg Wooledge <wooledg@eeg.ccf.org> wrote:
> On Fri, May 26, 2017 at 12:57:22PM -0400, gwmfms6@openmailbox.org wrote:
>> A virtual console (eg, Ctrl+Alt+F2) produces the correct result when I 
>> type ncal.
>> 
>> But if I type ncal in gnome-terminal, it starts the weeks with Sunday 
>> (which is wrong). GNOME problem, right? That's why /etc/default/locale 
>> isn't working how I expected?
>
> Yes, sounds like it.
>

This might be helpful to the OP.

https://lists.fedoraproject.org/pipermail/users/2014-December/455809.html


-- 
"It might be a vision--of a shell, of a wheelbarrow, of a fairy kingdom on the
far side of the hedge; or it might be the glory of speed; no one knew." --Mrs.
Ramsay, speculating on why her little daughter might be dashing about, in "To
the Lighthouse," by Virginia Woolf.

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

#181490

This definitely explains the problem (Thanks for contributing!), but I 
don't think it's a real solution because changing the Gnome region like 
described (although it does change LC_TIME) changes other variables (in 
addition to LC_TIME) that make no sense for the United States (eg., 
LC_NUMERIC, LC_MONETARY, LC_PAPER).

Denmark does LC_NUMERIC wrong (using a comma where there should be a 
decimal point). The United States does LC_TIME and LC_MEASUREMENT wrong.

I want to make everything proper and swapping to all en_DK variables 
fixes some things but not others. The only proper solution is to:

1) be able to change individual variables within Gnome (which I don't 
think is possible in current gnome)
2) create my own locale, which I do not know how to do. I've found two 
guides (linked below) for doing it but neither of them worked for me (I 
think the part about using localedef appears to not be working.)

https://unix.stackexchange.com/questions/136920/set-custom-locales-in-gnome3-on-fedora-20
https://askubuntu.com/questions/653008/how-to-create-a-new-system-locale


On 2017-05-27 06:10, Curt wrote:
> On 2017-05-26, Greg Wooledge <wooledg@eeg.ccf.org> wrote:
>> On Fri, May 26, 2017 at 12:57:22PM -0400, gwmfms6@openmailbox.org 
>> wrote:
>>> A virtual console (eg, Ctrl+Alt+F2) produces the correct result when 
>>> I
>>> type ncal.
>>> 
>>> But if I type ncal in gnome-terminal, it starts the weeks with Sunday
>>> (which is wrong). GNOME problem, right? That's why 
>>> /etc/default/locale
>>> isn't working how I expected?
>> 
>> Yes, sounds like it.
>> 
> 
> This might be helpful to the OP.
> 
> https://lists.fedoraproject.org/pipermail/users/2014-December/455809.html

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

#181494

On 2017-05-27, gwmfms6@openmailbox.org <gwmfms6@openmailbox.org> wrote:

> This definitely explains the problem (Thanks for contributing!), but I 
> don't think it's a real solution because changing the Gnome region like 
> described (although it does change LC_TIME) changes other variables (in 
> addition to LC_TIME) that make no sense for the United States (eg., 
> LC_NUMERIC, LC_MONETARY, LC_PAPER).
>
> Denmark does LC_NUMERIC wrong (using a comma where there should be a 
> decimal point). The United States does LC_TIME and LC_MEASUREMENT wrong.

Holy Jesus.

> I want to make everything proper and swapping to all en_DK variables 
> fixes some things but not others. The only proper solution is to:
>
> 1) be able to change individual variables within Gnome (which I don't 
> think is possible in current gnome)

> 2) create my own locale, which I do not know how to do. I've found two 
> guides (linked below) for doing it but neither of them worked for me (I 
> think the part about using localedef appears to not be working.)
>
> https://unix.stackexchange.com/questions/136920/set-custom-locales-in-gnome3-on-fedora-20
> https://askubuntu.com/questions/653008/how-to-create-a-new-system-locale
>

Define "appears to not be working." Anyhow, I believe someone here can
help you with this if only they'll pipe up (and you stop top-posting).

;-)

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

#181502

On 2017-05-27 10:20, Curt wrote:
> On 2017-05-27, gwmfms6@openmailbox.org <gwmfms6@openmailbox.org> wrote:
> 
>> This definitely explains the problem (Thanks for contributing!), but I
>> don't think it's a real solution because changing the Gnome region 
>> like
>> described (although it does change LC_TIME) changes other variables 
>> (in
>> addition to LC_TIME) that make no sense for the United States (eg.,
>> LC_NUMERIC, LC_MONETARY, LC_PAPER).
>> 
>> Denmark does LC_NUMERIC wrong (using a comma where there should be a
>> decimal point). The United States does LC_TIME and LC_MEASUREMENT 
>> wrong.
> 
> Holy Jesus.
> 
>> I want to make everything proper and swapping to all en_DK variables
>> fixes some things but not others. The only proper solution is to:
>> 
>> 1) be able to change individual variables within Gnome (which I don't
>> think is possible in current gnome)
> 
>> 2) create my own locale, which I do not know how to do. I've found two
>> guides (linked below) for doing it but neither of them worked for me 
>> (I
>> think the part about using localedef appears to not be working.)
>> 
>> https://unix.stackexchange.com/questions/136920/set-custom-locales-in-gnome3-on-fedora-20
>> https://askubuntu.com/questions/653008/how-to-create-a-new-system-locale
>> 
> 
> Define "appears to not be working." Anyhow, I believe someone here can
> help you with this if only they'll pipe up (and you stop top-posting).
> 
> ;-)

"Top-posting" is putting my writing above the quote? this is frowned 
upon? (or you were joking?). I wasn't aware top-posting was bad. I'll 
stop doing it.

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

#181504

On 2017-05-27, gwmfms6@openmailbox.org <gwmfms6@openmailbox.org> wrote:
>> 
>> Define "appears to not be working." Anyhow, I believe someone here can
>> help you with this if only they'll pipe up (and you stop top-posting).
>> 
>> ;-)
>
> "Top-posting" is putting my writing above the quote? this is frowned 
> upon? (or you were joking?). I wasn't aware top-posting was bad. I'll 
> stop doing it.
>

Normally, you should "interleave" your responses, trimming the material
not pertinent to your reply. 

I say this because bottom-posting (like bottom-fishing--well, not
precisely) in which the poster quotes (following others of his ilk) an
entire thread in order to make one superfluous comment at the bottom is
just as bad, if not worse (I think its worse), although the behavior is
seldom reprimanded.

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

#181510

On Saturday, May 27, 2017 11:39:03 AM Curt wrote:

> Normally, you should "interleave" your responses, trimming the material
> not pertinent to your reply.

+1
 
> I say this because bottom-posting (like bottom-fishing--well, not
> precisely) in which the poster quotes (following others of his ilk) an
> entire thread in order to make one superfluous comment at the bottom is
> just as bad, if not worse (I think its worse), although the behavior is
> seldom reprimanded.

+1

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

#181521

On 2017-05-27, Curt <curty@free.fr> wrote:
> On 2017-05-27, gwmfms6@openmailbox.org <gwmfms6@openmailbox.org> wrote:
>>> 
>>> Define "appears to not be working." Anyhow, I believe someone here can
>>> help you with this if only they'll pipe up (and you stop top-posting).
>>> 
>>> ;-)
>>
>> "Top-posting" is putting my writing above the quote? this is frowned 
>> upon? (or you were joking?). I wasn't aware top-posting was bad. I'll 
>> stop doing it.
>>
>
> Normally, you should "interleave" your responses, trimming the material
> not pertinent to your reply. 
>
> I say this because bottom-posting (like bottom-fishing--well, not
> precisely) in which the poster quotes (following others of his ilk) an
> entire thread in order to make one superfluous comment at the bottom is
> just as bad, if not worse (I think its worse), although the behavior is
                                     it's
> seldom reprimanded.
>
>


-- 
"It might be a vision--of a shell, of a wheelbarrow, of a fairy kingdom on the
far side of the hedge; or it might be the glory of speed; no one knew." --Mrs.
Ramsay, speculating on why her little daughter might be dashing about, in "To
the Lighthouse," by Virginia Woolf.

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

#181497

Op 27-05-17 om 14:33 schreef gwmfms6@openmailbox.org:
> Denmark does LC_NUMERIC wrong (using a comma where there should be a 
> decimal point).
Really? When did Denmark start using a decimal point instead of a comma?

Regards,
Frank

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

#181503

On 2017-05-27 10:49, Frank wrote:
> Op 27-05-17 om 14:33 schreef gwmfms6@openmailbox.org:
>> Denmark does LC_NUMERIC wrong (using a comma where there should be a 
>> decimal point).
> Really? When did Denmark start using a decimal point instead of a 
> comma?
> 
> Regards,
> Frank

A lot of Europe does it, and it is wrong! It goes back quite a while to 
when it was fashionable to use a dot (.) as a symbol for multiplication. 
So Europe stopped using a dot to signal a decimal point to avoid 
confusion (they should have stopped stopped using a dot as a symbol for 
multiplication). In the U.S. and G.B. an X was used for multiplication 
symbol so they continued on using a dot for decimal (as it should be).

God help the United States though with its continual reliance on the 
Imperial system for measurement and it's crazy date/time setup.

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

#181505

On Sat, 27 May 2017, at 16:24, gwmfms6@openmailbox.org wrote:

> A lot of Europe does it, and it is wrong! It goes back quite a while to 
> when it was fashionable to use a dot (.) as a symbol for multiplication. 

I don't think it's a straightforward as that.

Mathematics (at university level) uses dot that way, sometimes.  But is
also
uses adjacency of symbols so eg "xy" means x times y, as may "x.y".

> So Europe stopped using a dot to signal a decimal point to avoid 
> confusion (they should have stopped stopped using a dot as a symbol for 
> multiplication). In the U.S. and G.B. an X was used for multiplication 
> symbol so they continued on using a dot for decimal (as it should be).

But mathematics also used dot and x to refer to concepts named
dot-product
and cross-product.  

In other words, what's acceptable/normal depends entirely on the
audience.

-- 
Jeremy Nicoll - my opinions are my own.

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

#181506

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

L'octidi 8 prairial, an CCXXV, gwmfms6@openmailbox.org a écrit :
> A lot of Europe does it, and it is wrong! It goes back quite a while to when
> it was fashionable to use a dot (.) as a symbol for multiplication. So
> Europe stopped using a dot to signal a decimal point to avoid confusion
> (they should have stopped stopped using a dot as a symbol for
> multiplication). In the U.S. and G.B. an X was used for multiplication
> symbol so they continued on using a dot for decimal (as it should be).

What glyph is used as a separator does not really matter. What really
matter is that it is convenient and everybody uses the same. We could
have settled for a heart-shaped symbol, it would have worked.

In this matter, considerations such as "preserving local cultures" are
irrelevant. It is a matter of communication, an even of (slightly)
technical communication. Convenience and unambiguity are paramount.
Hence the "everybody uses the same" condition.

Convenience sets a few rules. The most important of these is: the
decimal separator, which has a semantic role, must be much more visible
than the thousand separator, which has only an aesthetic role. Thus, dot
for decimal and comma for thousand is stupid.

I suggest to apply the following rules, whenever you are free to chose
your rules:

- Be liberal in what you accept: understand both dots and commas, do not
  start a pedantic rant if you get a text with the "wrong" one.

- In "casual" computerized text, especially monospace, use dot for
  decimal and no thousand separator.

- In typeset text, use dot for decimal and a thin space for thousands
  (possibly: only if the range of the numbers exceeds 9999, i.e. no
  thousand separator for years for example).

- In hand-written text, the visibility of the dot is not reliable
  enough, use a comma for decimal. And a small space for thousand.

Regards,

-- 
  Nicolas George

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

#181507

On 2017-05-27 11:39, Nicolas George wrote:
> L'octidi 8 prairial, an CCXXV, gwmfms6@openmailbox.org a écrit :
>> A lot of Europe does it, and it is wrong! It goes back quite a while 
>> to when
>> it was fashionable to use a dot (.) as a symbol for multiplication. So
>> Europe stopped using a dot to signal a decimal point to avoid 
>> confusion
>> (they should have stopped stopped using a dot as a symbol for
>> multiplication). In the U.S. and G.B. an X was used for multiplication
>> symbol so they continued on using a dot for decimal (as it should be).
> 
> What glyph is used as a separator does not really matter. What really
> matter is that it is convenient and everybody uses the same. We could
> have settled for a heart-shaped symbol, it would have worked.
> 
> In this matter, considerations such as "preserving local cultures" are
> irrelevant. It is a matter of communication, an even of (slightly)
> technical communication. Convenience and unambiguity are paramount.
> Hence the "everybody uses the same" condition.
> 
> Convenience sets a few rules. The most important of these is: the
> decimal separator, which has a semantic role, must be much more visible
> than the thousand separator, which has only an aesthetic role. Thus, 
> dot
> for decimal and comma for thousand is stupid.
> 
> I suggest to apply the following rules, whenever you are free to chose
> your rules:
> 
> - Be liberal in what you accept: understand both dots and commas, do 
> not
>   start a pedantic rant if you get a text with the "wrong" one.
> 
> - In "casual" computerized text, especially monospace, use dot for
>   decimal and no thousand separator.
> 
> - In typeset text, use dot for decimal and a thin space for thousands
>   (possibly: only if the range of the numbers exceeds 9999, i.e. no
>   thousand separator for years for example).
> 
> - In hand-written text, the visibility of the dot is not reliable
>   enough, use a comma for decimal. And a small space for thousand.
> 
> Regards,

Okay, I didn't mean to start something. I was attempting some humor in 
my previous emails about LC_NUMERIC, please read them in that context. 
Obviously Denmark's numerics, currency, and paper size creates problems 
when residing in the USA so I can't just switch to that to solve the 
LC_TIME problem.

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

#181529

On Sat 27 May 2017 at 17:39:48 (+0200), Nicolas George wrote:

> L'octidi 8 prairial, an CCXXV, gwmfms6@openmailbox.org a écrit :
> > […]
> […]
> In this matter, considerations such as "preserving local cultures" are
> irrelevant.

An astonishing juxtaposition!

> Convenience sets a few rules. The most important of these is: the
> decimal separator, which has a semantic role, must be much more visible
> than the thousand separator, which has only an aesthetic role. Thus, dot
> for decimal and comma for thousand is stupid.

In view of your text following, "stupid" might be a bit strong. The
drift is certainly towards whitespace separators, in which case it
would no longer matter.

> I suggest to apply the following rules, whenever you are free to chose
> your rules:
> 
> - Be liberal in what you accept: understand both dots and commas, do not
>   start a pedantic rant if you get a text with the "wrong" one.
> 
> - In "casual" computerized text, especially monospace, use dot for
>   decimal and no thousand separator.
> 
> - In typeset text, use dot for decimal and a thin space for thousands
>   (possibly: only if the range of the numbers exceeds 9999, i.e. no
>   thousand separator for years for example).
> 
> - In hand-written text, the visibility of the dot is not reliable
>   enough, use a comma for decimal. And a small space for thousand.

Cheers,
David.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web