It could be my understanding that is failing. However, I believe that...
there is still an issue with the datepicker validation.

The datepicker picks the date, or the user enters the date into the field, but very early on in the posting of the values the date format goes from 02/02/1959 which was entered into the field, to what the

shows that the date format was changed to 1959-02-02, before it gets inspected by the validation logic, which returns a format error. Duh!

I don't expect any speedy fixes from you guys, but how's about a work around?
There are two dates on my form, and I'm stuck! Are there configuration settings for the datepicker that can be tweaked?

the validation rule "valid_date" works perfectly, too bad it doesn't exist.

I’ve been looking at the current date picker JavaScript, and it seems like it could use some TLC. It’s coded in an older JS style, which might be behind some of the quirks we’re seeing. I think it’s high time for a proper refactor to get it up to speed with modern practices.

Rewriting the date and time pickers is definitely on my to-do list. It’s a fair bit of work - estimating 3 to 7 days - but I’m planning to kick things off on March 21st. Looking forward to getting stuck in!

Also, I mentioned recently that I’d be happy to jump on Skype to check out your code and offer some help, no charge. I didn’t hear back, but just wanted to say the offer’s still open if you’d like to take me up on it.

Hi Charles,

Thanks for reporting the issue with the date picker validation. I've looked into it again, and it turns out the problem wasn't with the date picker JavaScript itself but rather how the date and time values were being handled on the server-side, particularly when loading existing records and validating submitted data.

I'm not sure if you were aware that the database stores dates in the standard YYYY-MM-DD format (and times often as HH:MM:SS). The issue arose because the server-side code wasn't consistently using the application's configured date format for display and validation.

Trongate allows setting a preferred date format via constants in config/config.php, like:

While these specific constants aren't currently detailed in the official documentation, they are used by the framework's date-handling functions and have been discussed in previous forum posts and some of DC's YouTube videos.

A contributing factor to the confusion is that the code generated by the Trongate Desktop app often defaults to using US-specific validation rules like `valid_datepicker_us` or `valid_datetimepicker_us`. If your `DEFAULT_DATE_FORMAT` is set differently (e.g., dd-mm-yyyy), these default rules will cause validation errors.

The fix involves two main parts in the controller, as you can see in my demo of `modules/bookings/controllers/Bookings.php`:

Formatting on Load: Ensuring dates/times loaded from the database are correctly formatted using the `DEFAULT_DATE_FORMAT` setting before being displayed in the form.


Using Generic Validation Rules: Changing the validation rules in the submit() method from the specific _us or _eu versions to the generic valid_datepicker and valid_datetimepicker. These generic rules are designed to automatically use the DEFAULT_DATE_FORMAT from your config file.


This approach ensures the form displays dates/times correctly based on the site configuration and validates them properly before saving them back to the database in the required `YYYY-MM-DD` format, regardless of the default code generated by the desktop app.

Separately, regarding the date picker itself, David (DC) has indeed been working on a significant rewrite of `trongate-datetime.js` to improve it for a more modern approach, and that work is about 90% complete. However, as explained above, the issue you encountered was related to the server-side handling rather than the picker's JavaScript.

Thanks again for bringing this to our attention! Let us know if you encounter any further issues.

Cheers,
DaFa