Dates on non-USA websites

Unfortunately I can’t reproduce this behaviour on a German based website. So it seems, the date format is not generally wrong on non-USA-browsers, but only for specific locales.

The code is based on https://github.com/jonthornton/jquery-timepicker – so I think, it should be possible to define a specific date format to make sure, it always works the same way regardless of the current locale of the browser.

Should be fixed with 2.11. The editor plugin should now always use mm/dd/yyyy, as this is the format the plugin expects in server side rules. Please let me know, if there are still problems.

Release 2.11 introduced another problem, sorry for the confusion :-(. I just released 2.12 which should work properly.

I updated the plugin, but when I select oct 7 on the drop-down menu, it still shows 07/10/2018 – and the program interprets that as july 10, so the problem still exists.

After further investigation it seems the drop-down menu defaults to the server’s format, instead of a non-ambiguous format like yyyy-mm-dd.

I can change the server setting to yyyy-mm-dd and then the drop-down menu shows the date in yyyy-mm-dd which works OK – but I thought you should know that there is an issue for those who use UK (and AUS) format.

PS thanks for the quick reply

• This reply was modified 6 years, 4 months ago by Alienne.
• This reply was modified 6 years, 4 months ago by Alienne.

This is really strange, because the plugin uses the jQuery date picker which does not know anything about the server date format. On my server I use “yyyy-mm-dd” as format and I still get “mm/dd/yyyy” in the date picker.

Did you try clearing the browser cache to make sure there is no old JavaScript code active?

Ok, I think there is a misunderstanding. You don’t talk about the TinyMCE plugin dialog but the rules? Because the rule editor indeed behaves different. I’ll fix this as soon as possible.

JFTR: I did not create the plugin in the first place but just started maintaining it as the original author did not have time anymore.

Unfortunately it’s much worse than I thought and I think, a working solution is not possible without rewriting a lot of code :-(.

The problem is, that date/time values in the rules are not stored as date and time but just plain text. When loading the rules, the plugin tries to parse these values according to the current date format of WordPress and in addition it tries to convert the WordPress date format to the format needed by the jQuery date picker. All this does not work well together and I don’t know when I have time to fix this mess – sorry.

So far I can only recommend to avoid rules alltogether and just use shortcodes with date/time values instead of rules.

Thanks anyway – since I know about the issue I can work around it, just thought others might need to be aware of the problem.

Otherwise it works fine.

Hi again,

I think I will finally be able to solve most of the problems with the weird date interpretation.

As far I can see, the original intention was to use exactly the same date format as it is configured in the WordPress settings – however the implementation is buggy and does not really work :-(.

1) the jQuery date picker needs a completely different format definition as PHP and the conversion can not always be done.

2) it is allowed to define any custom date format in WordPress you like – even leaving out the year or adding literals. So this format must never be used to read dates which are stored somewhere as text but only to output dates.

So I think the only reasonable way would be just to use ISO combined with the time zone for all dates (yyyy-mm-dd HH:MM tz). For example “2018-10-07 21:00 Australia/Sydney” for 7 October 2018, 9 pm in the timezone Australia/Sydney. If the timezone is missing, the timezone of the server on which WordPress is hosted, is used. This way it is always clear what date/time is being used and is not depending on any WordPress setting, which may be changed.

However – this also means, that all rules or existing shortcodes may become invalid with the update, when they don’t get converted from the local format to ISO. I try to figure out a way how to do this automatically, but I’m not sure yet if this is possible.

Good to see that this is being worked on; I just tried the plugin and started by adding a rule for the duration of the winter holidays, after which the ‘projected dates/times’ (where there was a ‘some problems’ warning even before I started) included a couple of dates for the year 1971, but hardly any for the dates I chose. This is a WordPress with German locale and “j. F Y” and “G:i” date/time formats. I understand the problems you are facing with the code. Resorting to shortcodes for now (which isn’t really a problem).

Just a quick update: I did a major code refactoring of the plugin. Hopefully I can release an update within the next 1-2 weeks which uses date/time values in ISO format only (yyyy-mm-dd HH:MM) while still being able to understand existing old values in rules or shortcodes. When editing old rules, the new version will automatically convert existing date values to the ISO style format.

I just released 2.50 which now uses ISO like format for date and time (yyyy-mm-dd HH:MM) and should fix the ambiguous behaviour.