Allow datepicker options to be overriden

I'm seeing this issue as well. Seems pretty presumptuous to hard code it to the American format when the rest of the world writes dates correctly :P

I will hopefully be able to write a patch to address this next week. I would be super helpful if the module maintainer could point me in a vague direction as to how to go about this/pointers/caveats. I'm hoping it will be just a matter of extending the if parameters around line 612 of better_exposed_filters_exposed_form_plugin.inc

Seems pretty presumptuous to hard code it to the American format when the rest of the world writes dates correctly :P

Couldn't agree more, though Y-M-D sorts better! :)

But the hardcoding is not in BEF. Drupal's standard date fields, when exposed as filters, are Y-M-D which is also the format the jQuery Datepicker gives you by default. So no conversion needed.

Custom Date-module fields are based on whatever the format is set for that field which can be whatever crazy format the user sets. Thus the big fat translation from PHP date formats to jQuery date formats so that the datepicker gives us a date in the format the textfield is expecting.

Unless you can show how to change the node post date filter, for example, to something other than Y-M-D I don't think the conversion is needed for those fields. Admittedly, I'm not well versed on date handling in Drupal core, so please reopen this issue if I'm missing something...

For me the date inserted by jQuery date picker is not Y-M-D, it is M-D-Y ie American date format.

On pages where I'm seeing this date format displayed I checked Drupal.settings.better_exposed_filters.bef_dateformat and it is set to "" ie no value. From this I assume that jQuery date picker is using it's default—which appears to be M-D-Y and not Y-M-D as you suggest. Can anyone else confirm this?

Re post filter dates: On the filter config page Views says it can take "A date in any machine readable format. CCYY-MM-DD HH:MM:SS is preferred."

So I think the real issue is the way Views handles entity date properties. They are probably being parsed with something like strtotime() which has no knowledge of the date format being passed to it and therefore BEF can't pass a date format to jQuery date picker.

mikeker, with your obvious in depth knowledge of Views filters, what do you think it would take to get a format customisable entity date property filter? Would it be a matter of patching Views itself or could it be a custom filter type provided by another module? (BEF for example :D)

There's possible scope in my current project to do either of these things but I just want to make sure I'm ploughing the right path.

sonictruth, you're absolutely correct: the datepicker uses M-D-Y as it's default format. Says so right there in the API docs! So I'm not sure what I was smoking when I said it was Y-M-D... And, yes, I believe that Views is using strtotime() behind the scenes to parse the date though it's been a long time since I was poking around in that part of the code.

For custom date fields, the Date API puts the format in the form itself but we don't have that with Drupal's core date fields.

Perhaps the best way to fix this is to add (in BEF) an advanced setting when the datepicker option is selected that allows you to pass an options array to be used when initializing the datepicker widget. That would allow a lot of other customization and would remove the need for me to sniff out date formats in custom date fields. I need to think about that a bit because it could break existing users if we suddenly pull the existing date formatting out from under them.

Regardless of the date picker though, the date format that needs to be displayed in the field still needs to be something that the Views filter is expecting. Because filters are user facing they need to be able to be adjusted to accept localized/specific formats on the front end.

There needs to be a way in the config to set the expected format for a filter then Views would then be able to convert it back to a timestamp for it's db query.

I realise this is really an issue for the Views issue queue but it would obviously affect the way that you implement the jQuery date picker.

Has this been addressed? Year old thread.... same issue just encountered

Not yet... Though patches are always welcome!

Sorry, I haven't had the time, nor paying projects needing BEF, to give this issue queue much love recently.

Subscribe.

I've added a translatable field for overriding the default datepicker options. This allows fine-grained control over the Datepicker settings and different settings per language.

Updating the title to reflect what actually happened in this issue.