gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Re: Possible solution for altering date formats (Deb


From: Rogerio Luz Coelho
Subject: Re: [Gnumed-devel] Re: Possible solution for altering date formats (Debian)?
Date: Thu, 2 Jul 2009 14:17:58 -0300

For me it's not the way I see the date, and this date not being what I am acostumed to ( dd-mm-yyyy) but if it CLEARLY says somewhere that the way GNUmed understands dates is YYYY-MM-DD , it will be ok ... what I think bothers me most is the CONFUSION, we may as well define a format now and end all this ...

I propose YYYY-MM-DD as it is ISO.

Rogerio



2009/7/2 Karsten Hilbert <address@hidden>
On Wed, Jul 01, 2009 at 07:24:19PM -0700, Jim Busser wrote:

> Solved! See below

Good.

>> Do you have "locales-all" installed ?
>
> I am not sure of the rationale (i.e. need) to install *all* locales and
> to consume hundreds of Mb to do so.

There is no need per se except for getting rid of some
headaches (as you experienced with this) at a nowadays petty
cost:

       apt-cache show locales-all | grep Installed-Size

               Installed-Size: 2796

This is roughly 3 Megabytes which fits into the cache of
modern CPUs let alone graphics adapters ...

>> all the LC_* can be set independently
>
> there was something in the Debian documentation about LANG serving to
> override some LC_settings, that was why I was looking at LANG

You are correct there. The locale system is fragile IMO.

> no but it is unclear how to set it at the user level

Easiest (AFAICT) is to set it manually.

> and despite that
> some Debian/Ubuntu postings suggest that the Gnome GUI menus are
> supposed to provide
>
>       System > Administration > Language Support
>
> but my lenny does not.

This may depend on some parts of the configuration UI being
installed or not - that would be my first guess there.

>>> So within the current session, as normal user jbusser, I did
>>>
>>>     LANG=en_DK.utf8
>>>     GDM_LANG=en_DK.utf8
>>>
>>> and then
>>>
>>>     &> LC_TIME=en_DK.utf8 ./gm-from-cvs.sh
>>>
>>> but it still made no difference in GNUmed.
>
>> Well, yeah, because en_DK.utf8 apparently displays dates the
>> same way as en_CA.utf8 (remember how I posted the screenshot
>> - which showed dates different from my de_DE but the same as
>> your en_CA ?)
>
> I got from
>       http://groups.google.com/group/linux.debian.user/browse_thread/
> thread/0b2171c1a2c858ba/389972095ee22c89?lnk=raot&pli=1
>
> to find out which locales on your system have the yyyy-mm-dd date
> format, run:
> grep ^d_fmt /usr/share/i18n/locales/* | ascii2uni -qaA | grep '%Y-%m-%d'
> My hint was at
>
> http://www.debian.org/doc/manuals/debian-reference/
> ch08.en.html#_the_reconfiguration_of_the_locale
>
> For some reason, the system default (despite having been altered to
> en_DK.UTF-8 by use of
>       sudo dpkg-reconfigure locales
>
> would not be used by other processes like the Xwindow manager and, for
> reasons I don't understand, even after en_DK.UTF-8 was installed and
> compiled and available to the regular user account as evidenced by
>
>       locale -a
>
> and even despite declaring in the console
>
>       LANG=en_DK.UTF-8
> and/or
>       LC_TIME=en_DK.UTF-8
>
> and various combination case with and without quotes, using "utf8" and
> "UTF-8" I could not get the environment and locale to display their
> acceptance for example locale -a would display
>
> LANG=en_CA.UTF-8
> LC_CTYPE="en_CA.UTF-8"
> LC_NUMERIC="en_CA.UTF-8"
> LC_TIME="en_CA.UTF-8"
> LC_COLLATE="en_CA.UTF-8"
> LC_MONETARY="en_CA.UTF-8"
> LC_MESSAGES="en_CA.UTF-8"
> LC_PAPER="en_CA.UTF-8"
> LC_NAME="en_CA.UTF-8"
> LC_ADDRESS="en_CA.UTF-8"
> LC_TELEPHONE="en_CA.UTF-8"
> LC_MEASUREMENT="en_CA.UTF-8"
> LC_IDENTIFICATION="en_CA.UTF-8"
> LC_ALL=
>
> or the LC_TIME line might be
>       LC_TIME=en_dk.UTF-8 (note absence of quotes)
>
> and when in the console I queried the date format I got
>
>       address@hidden:~$ locale -k d_fmt
>       d_fmt="%d/%m/%y"
>       address@hidden:~$
>
> but what I did was
>
> - go to user home ~/
> - create (I use pico editor) file .xessionrc
> - within it put
>       #!/bin/sh
>       LANG=en_DK.UTF-8
> - made executable (chmond +x .xessionrc)
> - restarted computer (maybe logging out & in user would have sufficed)
>
> - now witness locale:
>
> address@hidden:~$ locale
> LANG=en_DK.UTF-8
> LC_CTYPE="en_DK.UTF-8"
> LC_NUMERIC="en_DK.UTF-8"
> LC_TIME="en_DK.UTF-8"
> LC_COLLATE="en_DK.UTF-8"
> LC_MONETARY="en_DK.UTF-8"
> LC_MESSAGES="en_DK.UTF-8"
> LC_PAPER="en_DK.UTF-8"
> LC_NAME="en_DK.UTF-8"
> LC_ADDRESS="en_DK.UTF-8"
> LC_TELEPHONE="en_DK.UTF-8"
> LC_MEASUREMENT="en_DK.UTF-8"
> LC_IDENTIFICATION="en_DK.UTF-8"
> LC_ALL=
> address@hidden:~$
>
> - now witness screenshot after a regular
>       ./gm-from-cvs.sh
>
> Now I no longer have a problem which was, as a clinician, to be
> presented with items whose dates are showing as:
>
>       02/03/04
>       04/07/09
>       11/06/01
>
> when I cannot know if the above have been sorted on some parameter other
> than date, or even if date but I cannot see whether forward or reverse.

I think you perfectly prove the points that

a) the locale system works but is fragile and complicated

b) We shouldn't really use %x for formatting dates of any
  clinical significance.

So, now we are back to my earlier suggestion of pointing to
places where the date formatting should get fixed, and how.

Personally I don't have a problem with ISO YYYY-MM-DD but
that is definitely not going to be to everyones liking (but
I'd be fine with *that*, too :-)

Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


_______________________________________________
Gnumed-devel mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/gnumed-devel


reply via email to

[Prev in Thread] Current Thread [Next in Thread]