Thanks for writing back and yes, I have read the other thread, between you and Nigel.
Let me give you a brief overview so that it is clear what has been discussed so far and why I suggested having separate custom field for each month (and optionally for a year).
The Toolset's date/time type field stores the values in a UNIX timestamp format.
( ref: enlace oculto )
When time is enabled, it stores the exact time-based value for the selected date and when only the date is enabled, it stores the value of the selected date at midnight (12 am).
The code that Nigel provided in the other thread, helped to covert already stored date values at different times to this default midnight time, on the same dates. But we still don't have the information about the month stored separately anywhere.
> i can do the format="Y" - but this dont work.
- When we use format="Y", it shows the label or text value in the month format for the dropdown, but the actual comparison or filtering is still performed based on the stored UNIX timestamp values in the fields. which is why it doesn't work because those values represent a particular day and not a month.
That is why, you'll need an additional custom field to store the month's information if you'd like to filter by that.
And you don't necessarily need two separate fields for the month and the year. You can store them both in a single field, in a format like:
- Feb-24
- Jan-24
- Dec-23
- Nov-23
- Oct-23
...........
Depending on how these posts are being added and edited on the website, custom code can be used to programmatically update the value in this new custom field automatically, whenever a date is saved/updated, in the original date type field.
And for the posts where the date type field's value is already saved, custom code like the one Nigel shared earlier, can be used to automatically update the values in this new field too.
I hope this explanation helps and let me know if you have any follow-up questions.
