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 655573 - Incorrect date format on Windows
Incorrect date format on Windows
Status: RESOLVED FIXED
Product: libgoffice
Classification: Other
Component: General
unspecified
Other Windows
: Normal normal
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2011-07-29 12:13 UTC by Thomas
Modified: 2011-08-08 17:53 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
untested patch (553 bytes, patch)
2011-07-29 19:11 UTC, Andreas J. Guelzow
none Details | Review

Description Thomas 2011-07-29 12:13:42 UTC
The automatic date shortcut (Ctrl-. and Ctrl-;) delivers a date which is not formatted according to the OS locale settings.

Pressing Ctrl-. yields: "7.29.2011 14:05"

Correct would be: "2011-07-29 ..."
or
"29.07.2011 ..." (alternative German usage)

Country settings: German
Short date format: YYYY-MM-DD
Date separator: -
Long date format: DDDD, D. MMMM YYYY
Comment 1 Andreas J. Guelzow 2011-07-29 17:05:40 UTC
Since "7.29.2011 14:05" is not a valid date in C locale, Gnumeric clearly does not _ignore_ the locale but apparently the wrong date format is being assembled. In German locale on Linux I get:
29.7.2011 10:54
so this is probably a Windows-only issue.

Do you get the same result whether you use a completely unused (never used) cell or one that had previous content?

We are effectively creating the format of the date as
	int mbd = cell
		? gnm_format_month_before_day (gnm_cell_get_format (cell),
					       cell->value)
		: go_locale_month_before_day ();

	switch (mbd) {
	case 0:
		fmttxt = gnm_format_frob_slashes ("d/m/yyyy");
		break;
	default:
	case 1:
		fmttxt = gnm_format_frob_slashes ("m/d/yyyy");
		break;
	case 2:
		fmttxt = gnm_format_frob_slashes ("yyyy-m-d");
		break;
	}

	fmt = go_format_new_from_XL (fmttxt);
So, assuming an unused cell we depend on go_locale_month_before_day which apparently returns the wrong value for you.

Since this is a goffice function I am reassigning this bug to goffice. (Since this works fine under Linux I suspect that it will be further bumped to glib or so.)
Comment 2 Andreas J. Guelzow 2011-07-29 17:15:52 UTC
Perhaps we should in fact use one of the magic formats. If you enter a date and choose the cell format [$-f8f2]m/d/yy, what do you see as a result. On Linux in German locale I get something like:
29. 7. 11
Comment 3 Andreas J. Guelzow 2011-07-29 17:39:34 UTC
In goffice go_locale_month_before_day is effectively:

int
go_locale_month_before_day (void)
{
	static int month_first = 1;
	if (!date_order_cached) {
		date_order_cached = TRUE;

#if defined(G_OS_WIN32)
		{
			TCHAR str[2];
			GetLocaleInfo (LOCALE_USER_DEFAULT, LOCALE_IDATE, str, 2);
			month_first = str[0] != L'1';
			/* FIXME: Figure out if year comes first.  */
		}

#elif defined(HAVE_LANGINFO_H)
...
#else
...
#endif
	}

	return month_first;
}

So are you sure that your settings are in fact such that the day comes first?
Comment 4 Thomas 2011-07-29 18:17:21 UTC
(In reply to comment #3)

> So are you sure that your settings are in fact such that the day comes first?

No, see above. I have set:

Short date format: YYYY-MM-DD
Comment 5 Andreas J. Guelzow 2011-07-29 18:55:25 UTC
I missed that. 

So in go_locale_month_before_day str[0] should be 2, and month_first will be TRUE (ie. 1) which will result in go_locale_month_before_day to return 1 where we would want it to return 2.
Comment 6 Andreas J. Guelzow 2011-07-29 19:03:48 UTC
and on the Gnumeric side, 
gnm_format_frob_slashes ("yyyy-m-d");
is just a complicated
g_strdup("yyyy-m-d");
Comment 7 Andreas J. Guelzow 2011-07-29 19:11:17 UTC
Created attachment 192885 [details] [review]
untested patch

An untested patch that also considers ymd. Note that the non-Window's case already returns 2 for ymd.

According to  http://msdn.microsoft.com/en-us/library/dd373757%28VS.85%29.aspx we should probably considering using LOCALE_SSHORTDATE instead of LOCALE_IDATE.
Comment 8 Andreas J. Guelzow 2011-08-08 17:53:39 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.