Spanish; Castilian (Puerto Rico) and Spanish; Castilian (United States) Regional Formats use 24-hour format by default

Bug #1130501 reported by Walter Beckerleg
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GLibC
Fix Released
Medium
langpack-locales (Ubuntu)
Incomplete
Medium
Unassigned

Bug Description

The default format for the clock in the Spanish; Castilian (Puerto Rico) and Spanish; Castilian (United States) Regional Formats (selected in Language Support) is the 24-hour format (displays "13:30" rather than "1:30 PM"). These countries use the 12-hour format, so this default setting is incorrect. While you can change the clock format in the Date and Time Settings regardless of the current Regional Format, the clock in the Login Screen, the Guest Session, and any newly made User Account will use the default clock format (which is the 24-hour format in this case). In addition, I think it's worth mentioning that Valve's Steam gaming software is affected by this issue. Steam uses an "In-Game Overlay" that can display the current time to the user while playing a game. However, this Overlay clock uses the default clock format (again, this being the 24-hour format), even if the clock format for the current user is set to the 12-hour format.

Distro: Ubuntu 12.10

Package: indicator-datetime 12.10.2-0ubuntu3.1

Localization Files: es_PR [and] es_US

Revision history for this message
In , Law-redhat (law-redhat) wrote :

Back in November 2011, Uli checked in a large change which affected the LC_NUMERIC settings of various es_* locales. This change didn't reference any supporting documentation.

It's now being reported that various es_* locals have the wrong LC_NUMERIC settings for the decimal mark and thousands separator.

First I compared the es_* locales to CLDR for LC_NUMERIC settings. This turned up several differences (es_DO, es_GT, es_HN, es_MX, es_NI, es_PA, es_PE, es_PR, es_SV).

For each of those locales I then went in search of documents, preferably government documents which would show usage of the decimal mark and thousands separator.

Mexico:
http://www.economia.gob.mx/files/diagnostico_economia_mexicana.pdf

Dominican Republic:
http://www.bancentral.gov.do/noticias/avisos/aviso2010-06-25.pdf

We can get grouping from this document from the Guatemala Government. Once we know grouping uses ',', then the decimal mark must be '.'.
http://www.ine.gob.gt/np/enei/ENEI2011.htm

Honduras:
http://www.ine.gob.hn/drupal/node/175
http://archivo.laprensa.hn/Negocios/Ediciones/2011/02/07/Noticias/Tasa-de-desempleo-de-Honduras-subio-a-44

Nicaragua:
http://www.bcn.gob.ni/estadisticas/economicas_anuales/nicaragua_en_cifras/2010/Nicaragua_en_cifras2010.pdf

Panama:
http://www.mef.gob.pa/portal/2011-Comunicados/2011-DISMINUYESUSTANCIALMENTEELDESEMPLEOENPANAMA.html

Puerto Rico:
http://www.periodicolaperla.com/index.php?option=com_content&view=article&id=3606:en-puerto-rico-la-tasa-de-empleo-cae-al-nivel-mas-bajo-en-la-historia&catid=93:analisis-economico&Itemid=300

El Salvador:
http://www.minec.gob.sv/index.php?option=com_content&view=article&catid=1:noticias-ciudadano&id=1567:encuesta&Itemid=77

All the above referenced documents show a decimal mark as '.' and the thousands separator as ',', which indicate glibc's localedata is wrong.

Interestingly enough, Peru which was supposed to use '.' as the decimal separator and ',' as the thousands separator according to CLDR seems to do the opposite according to these government inflation and labor reports:

http://www.bcrp.gob.pe/docs/Publicaciones/Reporte-Inflacion/2010/marzo/Reporte-de-Inflacion-Marzo-2010.pdf
http://www.inei.gob.pe/biblioineipub/bancopub/Est/Lib0909/libro.pdf

Thus es_PE is correct as-is.

Revision history for this message
In , Law-redhat (law-redhat) wrote :

Created attachment 6600
Patch to fix various es_* locales

Revision history for this message
In , Keld Simonsen (keld) wrote :
Download full text (3.5 KiB)

On Wed, Aug 22, 2012 at 05:54:17PM +0000, law at redhat dot com wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id=14510
>
> Bug #: 14510
> Summary: LC_NUMERIC wrong for various latin america locales
> Product: glibc
> Version: 2.17
> Status: NEW
> Severity: normal
> Priority: P2
> Component: localedata
> AssignedTo: <email address hidden>
> ReportedBy: <email address hidden>
> CC: <email address hidden>
> Classification: Unclassified
>
>
> Back in November 2011, Uli checked in a large change which affected the
> LC_NUMERIC settings of various es_* locales. This change didn't reference any
> supporting documentation.
>
> It's now being reported that various es_* locals have the wrong LC_NUMERIC
> settings for the decimal mark and thousands separator.
>
> First I compared the es_* locales to CLDR for LC_NUMERIC settings. This turned
> up several differences (es_DO, es_GT, es_HN, es_MX, es_NI, es_PA, es_PE, es_PR,
> es_SV).
>
> For each of those locales I then went in search of documents, preferably
> government documents which would show usage of the decimal mark and thousands
> separator.
>
>
> Mexico:
> http://www.economia.gob.mx/files/diagnostico_economia_mexicana.pdf
>
> Dominican Republic:
> http://www.bancentral.gov.do/noticias/avisos/aviso2010-06-25.pdf
>
> We can get grouping from this document from the Guatemala Government. Once we
> know grouping uses ',', then the decimal mark must be '.'.
> http://www.ine.gob.gt/np/enei/ENEI2011.htm
>
> Honduras:
> http://www.ine.gob.hn/drupal/node/175
> http://archivo.laprensa.hn/Negocios/Ediciones/2011/02/07/Noticias/Tasa-de-desempleo-de-Honduras-subio-a-44
>
> Nicaragua:
> http://www.bcn.gob.ni/estadisticas/economicas_anuales/nicaragua_en_cifras/2010/Nicaragua_en_cifras2010.pdf
>
> Panama:
> http://www.mef.gob.pa/portal/2011-Comunicados/2011-DISMINUYESUSTANCIALMENTEELDESEMPLEOENPANAMA.html
>
> Puerto Rico:
> http://www.periodicolaperla.com/index.php?option=com_content&view=article&id=3606:en-puerto-rico-la-tasa-de-empleo-cae-al-nivel-mas-bajo-en-la-historia&catid=93:analisis-economico&Itemid=300
>
> El Salvador:
> http://www.minec.gob.sv/index.php?option=com_content&view=article&catid=1:noticias-ciudadano&id=1567:encuesta&Itemid=77
>
> All the above referenced documents show a decimal mark as '.' and the thousands
> separator as ',', which indicate glibc's localedata is wrong.
>
>
> Interestingly enough, Peru which was supposed to use '.' as the decimal
> separator and ',' as the thousands separator according to CLDR seems to do the
> opposite according to these government inflation and labor reports:
>
> http://www.bcrp.gob.pe/docs/Publicaciones/Reporte-Inflacion/2010/marzo/Reporte-de-Inflacion-Marzo-2010.pdf
> http://www.inei.gob.pe/biblioineipub/bancopub/Est/Lib0909/libro.pdf
>
> Thus es_PE is correct as-is.

I checked a few of your references. They were economic reports.
Not kind of normative specifications from a standards or language authority.
You can also in my country (Denmark) find examples of use of the decimal point, which is
not a...

Read more...

Revision history for this message
Matthew Paul Thomas (mpt) wrote :

If this is happening in Steam as well, it isn't indicator-datetime's fault. I'm told eglibc provides the locale data.

affects: indicator-datetime → eglibc (Ubuntu)
Changed in eglibc (Ubuntu):
importance: Undecided → Low
Revision history for this message
Walter Beckerleg (spayk-99) wrote :

I couldn't find eglibc on Synaptic, only a "eglibc-source", which was not marked as installed. How can I verify the version of eglibc that I have?

Revision history for this message
In , JorSol (jorsol) wrote :

I confirm that in Nicaragua the decimal_point is "." and thousands_sep is ","

affects: eglibc (Ubuntu) → langpack-locales (Ubuntu)
Changed in langpack-locales (Ubuntu):
status: New → Confirmed
Changed in glibc:
importance: Unknown → Medium
status: Unknown → Confirmed
Revision history for this message
In , Luis Dominguez (ldominguez-y) wrote :

In Mexico, the official regulation (NOM-008-SCFI-1993, and NOM-008-SCFI-2002) set the decimal sign is as in the IS; however, in 2009 both the comma and the point were declared valid. Unfortunately, these kind of regulations are not mandatory, and people use the other notation in daily use, or as in the examples by <email address hidden>

[ESP]
2009 reform: http://www.dof.gob.mx/nota_detalle.php?codigo=5111108&fecha=24/09/2009

Last release: http://www.amap.com.mx/download/26.NOM-008-SCFI-2002%20Sistema%20general%20de%20unidades%20de%20medida.pdf

Revision history for this message
In , Christian Servín (emileneth-h) wrote :

The reference:
"México: http://www.economia.gob.mx/files/diagnostico_economia_mexicana.pdf"

Is a gobernment document for formal informational purposes and it obeys a visual design (like a powrpoint presentation), it is not intended for computer systems I'm listing the troubles with this document:

a) Numerical data is presented with one, two or three decimals, depending on the precision needed in the graph or paragraph. For day to day computational numerical presentations two digit is good enough, just the same as en_US.
b) The document arbitrarily use Monetary format without the thousand separator ",", page 22 uses the notation 833,998 mdp (millions of pesos) without the $ symbol, but like the en_US we do use the $ symbol for money
c) Commonly the percentual values are good enough with %XX.x, math is math here and in china.

Latin American numerical keyboard uses the "." for decimal and it is important for us because when we make calculations with this keyboard its we use this key for fast typing, same as in en_US

Right now the locale is like the spaniard persons use it. We can use the es_ES way (decimal"," & thousands".") only when we exchange documents with en_ES country, but it is not very common.

In México as of Jan 2010 it was introduced an increment in tax, up to 16%, this value introduces troubles while calculating accounting balances when using only 2 decimal digits, so since that date accounting and monetary systems began to use 4 digit precision. Formatted monetary values must include all 4 digits to avoid manual transcription errors or precision errors during numerical methods.

For the same reason we also use 4 digits when exchanging currencies (same as en_US): http://finance.yahoo.com/q?s=USDMXN=X

This issue goes back to 2012, its time to make it right

See also:

http://publib.boulder.ibm.com/infocenter/forms/v3r5m0/index.jsp?topic=/com.ibm.form.designer.locales.doc/i_xfdl_r_formats_es_MX.html

http://lh.2xlibre.net/locale/es_MX/

http://www.localeplanet.com/icu/es-MX/

Revision history for this message
In , Christian Servín (emileneth-h) wrote :

I just edited my
/usr/share/i18n/locales/es_MX

From:
LC_NUMERIC

Revision history for this message
In , Christian Servín (emileneth-h) wrote :

I just edited my
/usr/share/i18n/locales/es_MX

From:
LC_NUMERIC
copy "es_ES"
END LC_NUMERIC

To:
LC_NUMERIC
copy "en_US"
END LC_NUMERIC

and inside LC_MONETARY
int_frac_digits4
frac_digits 4

Revision history for this message
In , Carlos-0 (carlos-0) wrote :

This issue has been fixed for a while now. Marking as fixed.

It does not fix the fractional digits for es_MX though, and those remain at 2. Please file a new bug to discuss making this 4.

localedata/ChangeLog

2012-09-05 Jeff Law <email address hidden>

        [BZ#14510]
        * locales/es_DO: Fix LC_NUMERIC decimal_point and thousands_sep.
        * locales/es_GT: Likewise.
        * locales/es_HN: Likewise.
        * locales/es_MX: Likewise.
        * locales/es_NI: Likewise.
        * locales/es_PA: Likewise.
        * locales/es_PR: Likewise.
        * locales/es_SV: Likewise.

Changed in glibc:
status: Confirmed → Fix Released
Changed in langpack-locales (Ubuntu):
status: Confirmed → Triaged
importance: Low → Medium
Revision history for this message
Gunnar Hjalmarsson (gunnarhj) wrote :

Thanks for your bug report, Walter.

For both of those locales, can you please provide a couple of links to e.g. large newspaper or governmental sites which show that the a.m./p.m. format is actually in use.

Changed in langpack-locales (Ubuntu):
status: Triaged → Incomplete
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.