Manually editing date field results in bogus date
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Indicator Date and Time |
Fix Committed
|
Undecided
|
Unassigned | ||
indicator-datetime (Ubuntu) |
Fix Released
|
Undecided
|
Matthew Paul Thomas |
Bug Description
If you manually edit the time field, the time correctly changes.
But if you manually edit the date field, it either:
A) Won't work (you'll see a warning in the terminal like "** (gnome-
B) Or screw up your date (if in Canada, it will reset it to epoch because it is interpreting a two-digit year, and trying to set the year to 13 CE)
This is because of https:/
But I think fixing that bug is ill advised. We can reliably format a date into a locale-specific display string. But as far as I recall, there is no way to either:
A) Programatically format a locale-specific display string back into a date
B) Or programatically query what the locale-specific display string breaks into (i.e. is "%x" really "%y-%m-%d"?)
So if we show the data in the locale-specific way, there's no way to parse it back again, when the user edits the text box.
We should go back to ISO 8601 display dates (or find a way to parse a locale string).
Related branches
- PS Jenkins bot (community): Approve (continuous-integration)
- Mathieu Trudel-Lapierre: Approve
-
Diff: 15 lines (+4/-1)1 file modifiedsrc/datetime-prefs.c (+4/-1)
OK. desrt informs me that we can get what "%x" means by calling nl_langinfo (D_FMT). But that would still only give us field names. We'd still have to write a parser to cover a lot of various cases.
And apparently some of the characters might be translated when we display in locale format. So we'd have to parse hindi numbers too. (needs confirmation)
This might not be worth the effort to get right. I'm personally advocating reverting the commit and using ISO 8601 dates.