Localized dates in smart playlists fail for - at least - en-AU

[rsjtdrjgfuzkfg]

As reported in the forums the smart playlist UI is using different APIs for parsing and formatting dates, causing dates to switch month and day on each focus change on en-AU. It is quite likely that other locales are affected as well.

Imho, we should evaluate the API used within the property (formatting) to be used for the UI-side parsing as well. In general, it seems like a good idea to keep this issue in mind when touching the PropertyInfo structures in general, as it is quite annoying to have formatting within the property and parsing within the UI - without a proper contract in between.

Fixing this issue for dates only seems like a small project to me (find all places where parsing happens within the UI, mostly Date.parse and replace it with something safe), but I don't have to actually do it right now. Feel free to claim this issue!

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/16569627-localized-dates-in-smart-playlists-fail-for-at-least-en-au?utm_campaign=plugin&utm_content=tracker%2F230233&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F230233&utm_medium=issues&utm_source=github).

[freaktechnik]

From what I remember, the Smart Playlists bindings always validate the input whenever the focus changes and then output the validated version, so the users sees if something changes. The validation makes the value usable within the SQL query, which is why the date changes, I'd assume. Fixing this would mean generating a validated version of the value for the UI and one for the query, and I'm not sure there is infrastructure to easily do that.

[rsjtdrjgfuzkfg]

@freaktechnik

From what I remember, the Smart Playlists bindings always validate the input whenever the focus changes and then output the validated version, so the users sees if something changes.

Yes. That's what is happening, but the validation alwasy assumes en-US format first, and outputs a local format. In case of en-AU, the local format is equal to en-US format up to the order of day and month. This causes day and month to switch on every focus change.

The validation makes the value usable within the SQL query, which is why the date changes, I'd assume.

From the code I read, no (that is, for dates. No idea about other types of data). Dates are stored as 11-digit string representing a decimal number (Milliseconds since Epoch or something similar, not that sure about the actual unit right now). The UI clearly doesn't display that.

Format: https://github.com/nightingale-media-player/nightingale-hacking/blob/sb-trunk-oldxul/components/property/src/sbDatetimePropertyInfo.cpp#L39

Use of format within formatting code: https://github.com/nightingale-media-player/nightingale-hacking/blob/sb-trunk-oldxul/components/property/src/sbDatetimePropertyInfo.cpp#L267