After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 494387 - Editing yyyy-mm-dd dates
Editing yyyy-mm-dd dates
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: GUI
git master
Other All
: Normal minor
: ---
Assigned To: Morten Welinder
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2007-11-07 00:17 UTC by Ed Schofield
Modified: 2007-11-07 03:18 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ed Schofield 2007-11-07 00:17:29 UTC
Please describe the problem:
Using Gnumeric 1.7.11 (Ubuntu Gutsy), enter the date 2007-11-06 into a cell.

(1) The date comes up as 2007-Nov-06. This is mildly annoying. Why should Gnumeric change the date format unasked?
(2) Hit F2. The date format is now apparently 6/11/2007, which is probably correct for my locale, but is inherently ambiguous.
(3) Change 6 to 7. This should logically increment the day to 7th November 2007, but now the date jumps crazily to 2007-Jul-11.
(4) Hit F2 again. The formula bar now reads 11/7/2007, which is insane. Hit enter, and it reverts to 2007-Nov-07.

Steps to reproduce:


Actual results:


Expected results:
I deliberately use the ISO 8601 format for dates whenever possible precisely to avoid problems of this kind. Gnumeric should store dates internally in one sane and unambiguous format (such as ISO 8601) and should not map dates entered by the user into other formats for display or editing purposes unless specifically requested to do so. It should especially not confuse itself through an internal dependence on one country's date format.

Does this happen every time?
Yes.

Other information:
I do not know what environment variables are set for Gnumeric when I start Gnumeric from the GNOME Applications menu. (My .bashrc file sets LC_TIME to en_DK.utf8, but I think GNOME does not spawn a new shell for each application launched from the menus.)

If I start gnumeric manually from a shell with the LC_TIME environment variable set to en_DK.utf8, dates are mishandled in a different way. In this case the date "2007-11-06" is still displayed as "2007-Nov-06", and F2 now displays the date as 11/6/2007, rather than the date format of my input or that indicated by the locale.
Comment 1 Morten Welinder 2007-11-07 02:02:00 UTC
1. We guess a reasonable format for the date you entered.  This is so dates
   end up in a mostly uniform format.  You can always override by setting the
   format you want.

2. We use a specific date format for editing because it is too cumbersome
   to edit some date format, notably those with weekdays and months-as-text.

   That format is "m/d/yyyy" or "d/m/yyyy" as appropriate.  (If cell format
   suggests m-before-d or d-before-m then use that; otherwise use locale.)

3. That was bug 472760.

4. A further consequence of 3.


So your real problem seems to be the heuristic for date entry format
described as (2) above.  Gnumeric does not notice that the year comes
first which makes the d/m order irrelevant.
Comment 2 Andreas J. Guelzow 2007-11-07 02:05:54 UTC
What is the correct format for your locale? In other words what is the output
when you run
locale -c LC_TIME

(I assume this doesn't really specify ISO 8601 format. If ISO 8601 is indeed your preferred format perhaps you should change your locale appropriately.)
Comment 3 Morten Welinder 2007-11-07 02:23:14 UTC
Andreas: locale format only enters into this if the cell does not have a
suitable date format already.
Comment 4 Morten Welinder 2007-11-07 03:18:55 UTC
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.