GNOME Bugzilla – Bug 33229
German locale and date input
Last modified: 2010-03-28 18:51:24 UTC
Package: gnumeric Severity: normal Version: 0.58 Synopsis: gnumeric - German locale and date input Class: sw-bug Distribution: Red Hat Linux release 6.2 (Zoot) System: Linux 2.2.17 i686 unknown C library: glibc-2.1.3-21 C compiler: egcs-2.91.66 glib: 1.2.8 GTK+: 1.2.8 ORBit: ORBit 0.5.4 gnome-libs: gnome-libs 1.2.8 libxml: 1.8.10 gnome-print: gnome-print-0.25 gnome-core: gnome-core 1.2.4 Description: When gnumeric 0.58 runs with the German locale (LANG=de_DE), it isn't possible to input dates in the normal German DD.MM.YY or DD.MM.YYYY format. Any date strings are only treated as text cells. The formats are missing a dd\.mm\.yyyy format, too. Martin ------- Bug moved to this database by debbugs-export@bugzilla.gnome.org 2001-01-27 12:33 ------- This bug was previously known as bug 33229 at http://bugs.gnome.org/ http://bugs.gnome.org/show_bug.cgi?id=33229 Originally filed under the Gnumeric product and general component. The original reporter (mj@m-j-s.net) of this bug does not have an account here. Reassigning to the exporter, debbugs-export@bugzilla.gnome.org. Reassigning to the default owner of the component, jgoldberg@home.com.
We currently hard code the date seperator because there is no obvious way to extract it from the locale. If anyone has ideas it is an easy fix.
*** Bug 65045 has been marked as a duplicate of this bug. ***
If we can't extract it from the locale, can we make it a preference setting?
I'd like to see this resolved but don't see a clean way to do it. Having a preference setting seems like a kludge because it would be gnumeric specific and hidden. We'll face the same problem with currencies. As soon as we stop using the locales, we'll need a system wide mechanism for configuring and replacing it.
We could extract it from a translation of a string like "12/31/2002" [US] which might be "31.12.2002" [DE].
That is even worse than a preference setting. We'd be creating a magic preference setting defined via the translation that is specific to gnumeric.
What about scanning the output of date +%x for an appropriate separator? in german: 14.10.2002 in english: 10/14/2002
The following little C proram returns the locale's date format: /* start */ #define _GNU_SOURCE #include <langinfo.h> #include <locale.h> int main (void) { unsigned char time_string[80]; setlocale (LC_ALL, ""); strcpy (time_string, nl_langinfo(D_FMT)); printf ("%s\n", time_string); return 0; } /* end */ Perhaps this could be used for constructing the appropriate default date format for the locale. If the locale has no date format defined or nl_langinfo can't be used, I suggest the ISO date format is used by default in those cases instead (http://www.cl.cam.ac.uk/~mgk25/iso-time.html).
Yes that is known we're already pretending to parse it to guess day-month vs month-day. We're going to need to parse even more of it to guess the default seperator.
*** Bug 119904 has been marked as a duplicate of this bug. ***
*** Bug 139932 has been marked as a duplicate of this bug. ***
*** Bug 370458 has been marked as a duplicate of this bug. ***
Currently Gnumeric will understand "24.12.2006" as a date as long as... 1. the cell into which it is entered has been formatted as a date with day before month. -or- 2. the locale has day before month, and the cell is *not* using a month- before-day format such as "m/d/y". That pretty much means that input works as expected. What is missing is that if you select a "dd.mm.yyyy" format (as a custom format, for now), you will hit bug 371351 and things will look wrong. Also missing is the right format in the Date part of the menu.
Created attachment 119045 [details] [review] Proposed goffice patch Use go_locale_get_date_format to provide the first format in the list of date formats.
Created attachment 119046 [details] [review] Proposed gnumeric patch Use the format identified by go_locale_get_date_format for date editing. Retain the day/month separator character the user used when processing date input.
Bringing this back on the radar.
Re. the src/gnm-format.c change: 1. If a cell has a format like yyyy-mm-dd, it gets very confusing if the editing format overrides that. 2. The result from go_locale_get_date_format is not necessarily suited for editing. It is meant for display. We really don't want weekdays or fully spelled-out month names for editing.
Re. the goffice patch: I am fairly certain that the correct format to use is "[-$f800]whatever", i.e., a format that magically adapts to the users locale. (Note, that f800 is defined in terms of go_locale_get_date_format, see go-format.c) Unlike Excel, I doubt we want to display that monstrosity in dialogs.
Re. the number-match.c patch: This will try to free some constant strings. Apart from that, this part of the patch can probably go in without waiting for the other parts. I'll deal with it.
number-match patch -- somewhat different from the one above -- is in. It should be a no-op for locales that use slashes.
Before we really start mucking with the dates in goffice, we need to make Gnumeric stop looking at them directly. Filed bug 575317 for that.
Date editing now also uses the locale separator. That ought to finish the Gnumeric part (not counting bug 575317 and whatever sum1 will come up with). Leaving open for the goffice part.
Created attachment 130716 [details] [review] Goffice patch This somewhat brutal patch cuts down on the number of date formats in the dialog. Further, it makes sure localized dates are present. Comments are most welcome.
Looks like some unwanted interaction with locale's decimal separator. For nb_NO.UTF-8, I get commas where there should be periods. dd,mm,yyyy etc.
Hmm... This is at least partly on purpose. The format is guess really is "dd.mm.yyyy". "dd.mm.yyyy" gets localized as "dd,mm,yyyy" and we display that. Note, that you actually get dots when you use that format. Excel might not localize those dots. I'll have to check.
Relatedly, 1-Jan-2000 [us] displays as 1-jan.-2000 in d-mmm-yyyy format. Note the dot. da_DK has just 1-jan-2000. Is that really how people write it in nb_NO? Currently we do not even accept 1-jan-2000 as input which is just plain evil.
Such punctuation is now optional on entry. Aka 1-jan-2000 is now a fine thing to enter.
> 1-Jan-2000 [us] displays as 1-jan.-2000 in d-mmm-yyyy format. > Note the dot. Is that really how people write it in nb_NO? No, they don't. But I've never seen hyphens and month names together at all. Hyphens are only used with the ISO 8601 format: 2000-01-01. With month names, you may see 1. mars 2000 - unabbreviated month 1. jan. 2000 - abbreviated month Always with day written as ordinal ("first"), indicated by period.
> "dd.mm.yyyy" gets localized as "dd,mm,yyyy" and we display that. > Note, that you actually get dots when you use that format. > Excel might not localize those dots. I'll have to check. I don't understand why anybody would want to localize them. In the dialog, the user sees dd,mm,yyyy, which is wrong. In the cell, he gets 25.8.1958, which is probably what he wants. This is confusing.
Localization has been improved. The problem was that we did not distinguish between dots that were decimal points and dots that were not. We not localize "dd.mm.yyyy mm:mm:ss.000" into "dd.mm.yyyy mm:mm:ss,000". Note the different treatment of dots.
Created attachment 130919 [details] [review] Updated patch This adds the f800 format. (The dialog shouldn't show the code directly, but that's a different problem.)
Created attachment 130989 [details] [review] Updates patch This patch adds more magic formats.
Created attachment 131000 [details] [review] Updated patch This patch takes care of time formats too.
Created attachment 131035 [details] [review] Updated patch This adds the magic date/time format.
*** Bug 167279 has been marked as a duplicate of this bug. ***
I think this has been completely resolved by now. If not, please open a new bug with whatever is left -- I have lost track.
Hi, I am looking at Gnumeric 1.10.1 on Ubuntu 10.4 Beta. Should the fix be in this version? Then I don't see it. In the Format Cells dialog, don't see a Date format anything like the usual German dd.mm.yy Do I have to set a locale first? But why? What locale exactly needs to be set? In KDE, I set the Region & Language "Short date format" to DD.MM.YYYY. No luck. Cheers!
Start Gnumerc in German locale: LANG=de_DE.UTF-8 gnumeric (I have no idea what KDE's setting is connected to, but it would appear that it is not the standard thing.) With this I see "dd.mm.yyyy" as the 4th option. The first three as the special "[$...]..." codes that change depending on what locale they are used in.