GNOME Bugzilla – Bug 644217
Date in Document properties hasn't locale format
Last modified: 2011-03-11 19:02:47 UTC
Created attachment 182844 [details] Document Properties dialog screenshot Created and Modified date hasn't right locale format in Document Properties dialog. Accessed date is OK. See the attachment.
Created attachment 182852 [details] [review] Tentative patch Something like this ought to work, but I am not sure of the consequences. Andreas: ?
I committed the dialog part of this. We certainly that.
It works for saved files now. For new unsaved file Created date is displayed only and this date is still bad.
> It works for saved files now. Assuming that "now" means the current state of git, then that is the expected result. The rest of the patch is needed for newly "Created" documents.
Review of attachment 182852 [details] [review]: I think there are problems with this patch: 1) It introduces inconsistencies: We cannot recognize if arbitrary properties are containing date strings. So on the properties tab only the known ones are changed to locale while the unknown ones are kept as time stamps, for example in some of my files there is meta:printdate. 2) I would expect the properties page to show the true meta data as saved in the file rather than some modified version. This may become important when we implement the addition of user meta properties. (That does not seem to be implemented at this time.)
The inconsistency is already there: when read from opendoc or xls, we recognize things as dates. future setting of meta:printdate (from gnumeric) would be marked as timestamps and rendered accordingly. (I note now that things of type GsfTimestamp do not round-trip via .gnumeric -- that's pretty bad.)
Okay, please commit. We should probably fix the round-trip through gnumeric though. :-)
Patch committed. Keeping open for a look at .gnumeric persistence.
Created attachment 183172 [details] [review] gsf patch This patch (for libgsf) does... 1. Fix a typo where dates got marked "data". 2. Honour the type on load. Comments? Should files incorrectly marked "data" be read as "date"?
Also note that lots of types get mapped into double case G_TYPE_INT: case G_TYPE_UINT: case G_TYPE_LONG: case G_TYPE_ULONG: case G_TYPE_FLOAT: case G_TYPE_DOUBLE: type_name = "float"; and string: case G_TYPE_CHAR: case G_TYPE_UCHAR: case G_TYPE_STRING: case G_TYPE_ENUM: case G_TYPE_FLAGS: type_name = "string"; This isn't new.
I would think that the answer to "Should files incorrectly marked "data" be read as "date"?" should be: yes, definitely!
Otherwise the patch looks good to me.
This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.