wrong LC_TIME in Italian

Bug #420609 reported by Nicolò Chieffo
22
This bug affects 2 people
Affects Status Importance Assigned to Milestone
GLibC
Fix Released
Medium
eglibc (Ubuntu)
Fix Released
Low
Unassigned
glibc (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Accordingly to this file [1], this newspaper [2], and also because I'm Italian, there is an error in the way the date is displayed in linux.
The correct format for Italian speakers is:
day_name day_number month_name year, HH:MM:SS, time_zone

in the LC_TIME date_fmt things are really mixed up and should be changed to:
%a %e %b %Y, %H:%M:%S, %Z

the file localedata/locales/it_IT needs to be changed, but I can't understand how, since there are only strange codes

[1]: ftp://ftp.software.ibm.com/software/globalization/locales/Italy-Italian_Date.pdf
[2]: http://www.corriere.it/

Revision history for this message
In , Nicolò Chieffo (yelo3) wrote :

Accordingly to this file [1] and also because I'm Italian, I've seen
an error in the way the date is displayed in linux.
The correct formati for Italian speakers is:
day_name day_number month_name year HH:MM:SS

in the LC_TIME date_fmt things are really mixed up and should be changed to:
%a %e %b %Y, %H:%M:%S, %Z

[1]:
ftp://ftp.software.ibm.com/software/globalization/locales/Italy-Italian_Date.pdf

Revision history for this message
In , Nicolò Chieffo (yelo3) wrote :

popular Italian newspaper: http://www.corriere.it
the date is under the title "CORRIERE DELLA SERA", in the middle

Revision history for this message
In , Nicolò Chieffo (yelo3) wrote :

Created attachment 4070
italy.patch

possible patch, that swaps the fields. It does not add the "," since I don't
know if it must be added or not

Revision history for this message
In , Nicolò Chieffo (yelo3) wrote :

Is this the correct place, or should I ask in another bugzilla?

Nicolò Chieffo (yelo3)
description: updated
Revision history for this message
In , Nicolò Chieffo (yelo3) wrote :

I'm sorry to ping you again, but I think this is an important and very simple
bug that can be fixed in 2 minutes, and a patch is present. It just needs your
attention

Revision history for this message
Nicolò Chieffo (yelo3) wrote :

This is a really simple bug to fix.
I know it needs to be fixed upstream bug I didn't manage to get attention by anyone.

tags: added: regression-potential
Revision history for this message
Paolo Sammicheli (xdatap1) wrote :

Confirmed in Karmic Koala Beta.

Both date command and GNOME Clock 2.28.0 affected

Revision history for this message
Paolo Sammicheli (xdatap1) wrote :

on other hands, Jaunty Jackalope, date command affected but GNOME Clock 2.26.0 *not* affected.

Revision history for this message
Paolo Sammicheli (xdatap1) wrote :

Previous tests related to Karmic Koala ISO Image with Live CD, starting to investigate with daily updates. More datails coming soon.

Changed in glibc (Ubuntu):
assignee: nobody → Paolo Sammicheli (xdatap1)
status: New → Confirmed
Revision history for this message
Luca Ferretti (elle.uca) wrote :

Nicolò, I've seen your proposed a patch againg eglibc upstream, just a couple of questions:
 1) did you compared the locale data for it_IT (and it_CH, of course) provided by eglibc with the one in glibc? any difference? in case, any hope to "backport" the patch/fix from eglibc to glibc?
 2) there is another long date issue in those locale date for Italian: the usage of : in time specification. It's a common misbehavior, the historical separator is the "." (BTW, note that it should be, for example, "20.13.21,965182530", not "20.13.21.965182530"). Could you please update your patch accordly?

Revision history for this message
Nicolò Chieffo (yelo3) wrote :

To tell the truth I've not tested the patch, so I don't know if it will result in a correct thing. And the patch is not complete.

1) on the eglibc mailing list they say that they just copied the tree. In fact they don't want a fix in eglibc, but directly in glibc.
2) I'm not sure that the historical separator is "." do you have a reference? In the IBM reference they say it's ":" We need to find something official. Is there an organization which have this information?

the final patch should generate a format like this (either with . or :)
ven 9 ott 2009, 11:52:15, CEST 2009

Now it is
ven ott 9 11:52:15 CEST 2009

Revision history for this message
Paolo Sammicheli (xdatap1) wrote :

Update on affected system:

Jaunty Jackalope

- date: Yes
- Clock: No

Karmic Koala Beta Live

- date: Yes
- Clock: Yes

Karmic Koala Beta Installed

- date: Yes
- Clock: No

I hope this will help.

Changed in glibc (Ubuntu):
assignee: Paolo Sammicheli (xdatap1) → nobody
Revision history for this message
Nicolò Chieffo (yelo3) wrote :

Sorry I wanted to say "ven 9 ott 2009, 11:52:15, CEST"

Changed in glibc:
status: Unknown → In Progress
Revision history for this message
Nicolò Chieffo (yelo3) wrote :

this patch does

"%a %e %b %Y, %H.%M.%S, %Z"

Revision history for this message
In , Nicolò Chieffo (yelo3) wrote :

Created attachment 4263
italian.patch

This is the correct format (note that : is now .)
updated patch accordingly.

"%a %e %b %Y, %H.%M.%S, %Z"

Now you just need to commit

Revision history for this message
In , Nicolò Chieffo (yelo3) wrote :

Is this bugzilla dead??

Revision history for this message
Steve Langasek (vorlon) wrote :

The glibc source package is no longer present in karmic, so marking this task as invalid. This should be addressed in the eglibc package.

Changed in glibc (Ubuntu):
status: Confirmed → Invalid
Changed in eglibc (Ubuntu):
status: New → Triaged
importance: Undecided → Low
Revision history for this message
In , Drepper-fsp (drepper-fsp) wrote :

I've added the changes.

Changed in glibc:
status: In Progress → Fix Released
tags: added: regression-release
removed: regression-potential
Revision history for this message
Matthias Klose (doko) wrote :

this should be fixed in lucid. please recheck and reopen if necessary

Changed in eglibc (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Nicolò Chieffo (yelo3) wrote :

Unfortunately date still prints the uncorrect format in my installation

Changed in eglibc (Ubuntu):
status: Fix Released → Confirmed
Revision history for this message
Matthias Klose (doko) wrote :

what is the output of dpkg -l libc6?

Revision history for this message
Nicolò Chieffo (yelo3) wrote : Re: [Bug 420609] Re: wrong LC_TIME in Italian

2.11.1-0ubuntu2
That's quite strange, I've controlled the source file and my patch was
applied... but `date` still gives me the wrong output.
Is there any command (or C function) to get date_fmt?

Revision history for this message
Nicolò Chieffo (yelo3) wrote :

now it seems to work

Changed in eglibc (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
In , Nicolò Chieffo (yelo3) wrote :

Created attachment 4879
lc_time_italian.patch

New patch.
Just a question: what's the differnce betwen date_fmt and d_t_fmt?
Thanks!

Revision history for this message
In , Petr Baudis (pasky) wrote :

What are you changing again and why with this new patch? Can you add a changelog
entry too?

Revision history for this message
In , Nicolò Chieffo (yelo3) wrote :

I'll answer tomorrow, since I have to look back at the patch because I forgot
the changelog.

Can you tell me the difference from date_fmt and d_t_fmt?

Revision history for this message
In , Petr Baudis (pasky) wrote :

Frankly, I have not been able to figure what date_fmt is good for quickly - its
purpose seems to be the same as d_fmt, but I cannot find it being used anywhere
within glibc...

Revision history for this message
In , Andreas Schwab (schwab-linux-m68k) wrote :

It's the default date(1) format.

Revision history for this message
In , Nicolò Chieffo (yelo3) wrote :

So there's no reason for them to be different, right?

Revision history for this message
In , Nicolò Chieffo (yelo3) wrote :

Created attachment 5001
lc_time_italian.patch

This patch contains the changelog, and drops the bits for it_CH since I'm from
Italy, not from Switzerland.

Revision history for this message
In , Nicolò Chieffo (yelo3) wrote :

reopening due to adding the changelog

Revision history for this message
In , Nicolò Chieffo (yelo3) wrote :

Created attachment 5002
lc_time_italian.patch

Sorry, I forgot to add a comment

Revision history for this message
In , Bugtrack (bugtrack) wrote :

Nicolo,
different date and time formats are used depending from format :
% Appropriate date and time representation
date_fmt ...
% Appropriate date and time representation (%c) with abbreviations
d_t_fmt ...
% Appropriate date representation (%x)
d_fmt ...
% Appropriate time representation (%X)
t_fmt ...

Revision history for this message
In , Nicolò Chieffo (yelo3) wrote :

Ok, so I will change date_fmt to not contain abbreviations.
What about the timezone? Should it be present for both date_fmt and d_fmt?

Changed in glibc:
importance: Unknown → Medium
status: Fix Released → Confirmed
Revision history for this message
In , Digitalfreak (digitalfreak) wrote :

Much has changed since the last patch has been attached therefore it does not apply cleanly now.

For Italian [1] CLDR says that the correct medium date format is "d MMM y" (5 set 1999), correct medium time format is "HH:mm:ss" (13:25:59), correct medium date and time format is "d MMM y, HH:mm:ss" (5 set 1999, 13:25:59).

For Italian in Switzerland [2] it provides the same data although marks them as "unconfirmed".

(In reply to Nicolo' Chieffo from comment #18)
> Ok, so I will change date_fmt to not contain abbreviations.

I've checked some locales and they all contain abbreviations in date_fmt so I think it is perfectly OK to contain abbreviations.

> What about the timezone? Should it be present for both date_fmt and d_fmt?

Most (but not all) of the locales contain the timezone in d_t_fmt but the default C locale does not. Therefore I think it is correct not to include the timezone in d_t_fmt but include it in date_fmt.

Now about the patch:

> * d_t_fmt: "%a %e %b %Y, %T, %Z"
> - remove the leading zero in the day of month using '%e' instead of '%b'

Good idea but I think you'd rather use "%-d" which means "do not pad with zero". "%e" means "pad with space", "%-e" means "do not pad with space" and therefore has the same effect as "%-d". Also, I think that the timezone should be removed.

I will write a new patch and replace it with "%-d" and remove ", %Z".

> - add ',' to separate date, time and timezone

Good, CLDR says that date and time should be separated with a comma.

> * t_fmt: "%H.%M.%S"
> - express the time in the expanded way instead of using '%T', to be sure to
> use the correct values

CLDR says there should be colons rather than dots therefore I will reject this change. Also I will restore the format with colons in date_fmt. "%T" means that "%H:%M:%S" is used literally therefore it is correct.

> * date_fmt: "%c"
> - make date_fmt and d_t_fmt the same

As said above, date_fmt should contain the timezone while d_t_fmt (which is used by "%c") should not. Therefore I think that the correct date_fmt should be "%a %-d %b %Y, %T, %Z" (ven 14 set 2018, 22:07:41, CEST)

Also, I will change d_fmt in it_CH from "%d. %m. %y" (which looks bad) to "%d.%m.%Y" (which is the same as de_CH and is almost the same as CLDR suggests). I will not change d_fmt in it_IT because it looks almost the same as CLDR. (In both cases CLDR suggests two-digit year while we have four digits.)

[1] http://st.unicode.org/cldr-apps/v#/it/Gregorian/
[2] http://st.unicode.org/cldr-apps/v#/it_CH/Gregorian/

Revision history for this message
In , Digitalfreak (digitalfreak) wrote :

Created attachment 11247
Proposed final solution

Revision history for this message
In , Cvs-commit (cvs-commit) wrote :

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via 434d45fd70ac1a137d01b715ea99c03ce3c21b14 (commit)
      from 7abf97bed9c24464a8a68fb9f9fe8d1e55c6b54c (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=434d45fd70ac1a137d01b715ea99c03ce3c21b14

commit 434d45fd70ac1a137d01b715ea99c03ce3c21b14
Author: Rafal Luzynski <email address hidden>
Date: Fri Sep 14 22:43:02 2018 +0200

    it_CH/it_IT locales: Correct some LC_TIME formats (bug 10425).

    Synchronize some values with CLDR and apply some suggestions from Bugzilla.

     [BZ #10425]
     * localedata/locales/it_IT (d_t_fmt): Use "%a %-d %b %Y, %T".
     (date_fmt): Use "%a %-d %b %Y, %T, %Z".
     * localedata/locales/it_CH (d_t_fmt): Use "%a %-d %b %Y, %T"
     which is the same as in it_IT.
     (d_fmt): Use "%d.%m.%Y" which is the same as in de_CH.
     (date_fmt): Use "%a %-d %b %Y, %T, %Z" which is the same as in it_IT.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog | 10 ++++++++++
 localedata/locales/it_CH | 6 +++---
 localedata/locales/it_IT | 4 ++--
 3 files changed, 15 insertions(+), 5 deletions(-)

Revision history for this message
In , Digitalfreak (digitalfreak) wrote :

Commit 434d45f fixes the issue.

Changed in glibc:
status: Confirmed → Fix Released
Revision history for this message
In , Cvs-commit (cvs-commit) wrote :
Download full text (40.9 KiB)

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The annotated tag, glibc-2.29 has been created
        at e7c9e41bb2407b0150997b382b49a5f3bb579bf9 (tag)
   tagging 56c86f5dd516284558e106d04b92875d5b623b7a (commit)
  replaces glibc-2.28.9000
 tagged by Siddhesh Poyarekar
        on Thu Jan 31 22:24:07 2019 +0530

- Log -----------------------------------------------------------------
The GNU C Library
=================

The GNU C Library version 2.29 is now available.

The GNU C Library is used as *the* C library in the GNU system and
in GNU/Linux systems, as well as many other systems that use Linux
as the kernel.

The GNU C Library is primarily designed to be a portable
and high performance C library. It follows all relevant
standards including ISO C11 and POSIX.1-2008. It is also
internationalized and has one of the most complete
internationalization interfaces known.

The GNU C Library webpage is at http://www.gnu.org/software/libc/

Packages for the 2.29 release may be downloaded from:
        http://ftpmirror.gnu.org/libc/
        http://ftp.gnu.org/gnu/libc/

The mirror list is at http://www.gnu.org/order/ftp.html

NEWS for version 2.29
====================

* The getcpu wrapper function has been added, which returns the currently
  used CPU and NUMA node. This function is Linux-specific.

* A new convenience target has been added for distribution maintainers
  to build and install all locales as directories with files. The new
  target is run by issuing the following command in your build tree:
  'make localedata/install-locale-files', with an optional DESTDIR
  to set the install root if you wish to install into a non-default
  configured location.

* Optimized generic exp, exp2, log, log2, pow, sinf, cosf, sincosf and tanf.

* The reallocarray function is now declared under _DEFAULT_SOURCE, not just
  for _GNU_SOURCE, to match BSD environments.

* For powercp64le ABI, Transactional Lock Elision is now enabled iff kernel
  indicates that it will abort the transaction prior to entering the kernel
  (PPC_FEATURE2_HTM_NOSC on hwcap2). On older kernels the transaction is
  suspended, and this caused some undefined side-effects issues by aborting
  transactions manually. Glibc avoided it by abort transactions manually on
  each syscall, but it lead to performance issues on newer kernels where the
  HTM state is saved and restore lazily (the state being saved even when the
  process actually does not use HTM).

* The functions posix_spawn_file_actions_addchdir_np and
  posix_spawn_file_actions_addfchdir_np have been added, enabling
  posix_spawn and posix_spawnp to run the new process in a different
  directory. These functions are GNU extensions. The function
  posix_spawn_file_actions_addchdir_np is similar to the Solaris function
  of the same name.

* The popen and system do not run atfork handlers anymore (BZ#17490).
  Although it is a possible POSIX violation, the POSIX rationale in
  pthread_atfork documentation regarding atfork handlers is to handle
  inconsistent mutex state afte...

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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