Hi. I'm working with some code that I inherited for a web app which maintains data for an apple farm, about the production and pallet storage. The very first HTML form allows for a Date/ Time picker.
The code leverages a PHP “framework” called GeoLib. I think that’s where the problem is, but i’m not sure. (liink to GeoLib http://geotonics.com/#geolib . )

This plugin interacts with a database for an apple farm about picking apples. At basically step 1 of this plugin’s functionality, it’s asking for a date of entry. The date picker is apparently where it’s breaking down. When the data is posted, the entered date is returned invalid. E.g.
"2022-01-09T15:31" is not a valid date.

I can change that value in the HTML input field to the following format (basically just removing the “T” before the Time, and putting it into 12-hr format… for whatever reason). Obviously, that defeats the purpose of the date picker. Changing the input field, manually after the error, and submitting again with the following format is accepted:
2022-01-09 03:31 PM

what date function should I use to "sanitize" that data so the data picker is satisfactory?

    $submitted = '2022-01-09T15:31';

$reformatted = DateTime::CreateFromFormat('Y-m-d\TH:i', $submitted)->format('Y-m-d h:i A');

    There's the question of why whatever it is you have upstream doesn't like standard ISO-formatted timestamps (it might even be the solution is just to stick :00 on the end)...

    Weedpacket
    Thank you!

    What exactly is happening with the escaped T, in
    DateTime::CreateFromFormat('Y-m-d\TH:i', $submitted)->format('Y-m-d h:i A');
    ?

      25 days later

      Turns out, it was a jQuery thing with the date formatting. Never did figure it out. That whole GeoLib thing just really gave me a headache! (sorry, Author...)

      I was able to finish the project using an old backup, and a bit of tweaking.
      Thanks for your help!

        Write a Reply...