I’m having trouble with a calendar view that allows the addition of new rows with datetime fields.
When the date format is ambiguous, the calendar view seems to interpret it as MM/DD/YYYY.
But the ‘add entry’ datetime form that creates the row stores it as DD/MM/YYYY, in accordance with my locale.
At the moment, this means that the user selects the date, correctly, from the ‘choose date’ interface, and it is stored by default as DD/MM. It is then displayed in the calendar view transposed, so some of the events are under the wrong date and so out of order, and the ‘edit date’ dialog subsequently interprets it in the new (transposed) date format, MM/DD.
The screenshots below show the creation, display, and editing, of the same entry. You can see that the default ‘now’ value is interpreted and stored as DD/MM, but is subsequently interpreted as MM/DD.
Is there a workaround for this? I can’t currently see any way to change the format that the default ‘now’ placeholder adopts, and I’m struggling to understand why subsequent interactions with the datetime object it creates aren’t subject to the same locale defaults.
I spent up to a hour on this before posting and, typically, I’ve fixed it within half an hour of asking for help.
This option is the solution:
‘Long’ format datetimes are not ambiguous, even on dates like 1st March. So if you pick that, it works. I previously had it as ‘Medium’, but I’d rather the dates work correctly than that they’re formatted right.
Agreed. Everybody and every computer can agree that yyyy-mm-dd means the same thing to everybody worldwide. Not like these crazy people that think day should come before month.
