Displaying dates using proform

How To
1

I have a field in the database that stores dates in timestamp format, I am using the proform “date” element to display the date.

I am using the dynamic value to retrieve the date, but it is generating an anomaly, because even though I set the correct date format for Brazil, an alert is being generated at run time and the element loads the date of the day.

Can someone help me?

2

What are you storing these date fields in, i.e. ACF, MetaBox etc? I’ve had problems when my return format in ACF was set different than the Pro Forms Date field.

Regards
Pete

1 Like
3

Yes, as @londonpete mentioned, the return format for the date in ACF must match the Pro Forms date field return format; otherwise, it will return today’s date.

I wish we could have an option in Bricksforge similar to ACF, where we define the display format on the frontend as well as the return format.

4

Surely if ACF has a display format and a return format, BF should honour that. My clients don’t really understand anything other than dd/mm/yy which ACF allows even though it’s stored in the database as Y-mm-dd etc

Regards
Pete

5

This has been a problem for such a long time and still hasn’t been fixed. Please address this ASAP, it is so fundamental

6

Guys, Daniele came up with an interim solution and has it on his radar for a permanent solution. See https://forum.bricksforge.io/t/acf-date-field-not-being-formatted-correctly-in-pro-forms/5264/3

7

Hi everyone,

Pete is right, the thread he linked has the current state. Short recap here so nobody has to jump back and forth.

The cause: the Date field puts the pre-filled value straight into the input, and flatpickr then parses it with exactly the pattern set under “Date Format”. There is no separate incoming format yet. So if the stored value looks different than what the field displays - a Unix timestamp, or ACF’s Ymd - parsing fails, you get the warning in the console, and the picker ends up on the wrong date, typically today’s.

Two ways to solve it today.

Without code: set the ACF return format to exactly the same pattern as the field’s “Date Format”, and use the “Save in database as” option to store it back as Ymd on submit. One honest caveat - that save conversion runs through PHP’s strtotime, which reads slash dates like 16/01/2026 in month/day order. So this route is reliable with dots or dashes, but not with dd/mm/yyyy.

With a small filter: flatpickr supports two independent formats, dateFormat for the value that is loaded and submitted, and altFormat for what the visitor sees. For the nestable Date element:

add_filter('bricksforge/pro_forms/datepicker_options', function ($options, $element) {
    $options['dateFormat'] = 'Ymd';
    $options['altFormat'] = 'd/m/Y';
    return $options;
}, 10, 2);

Set the ACF return format to Ymd to match, and leave “Save in database as” empty. For the classic (non-nestable) Pro Forms element the filter is bricks/element/form/datepicker_options.

@jacastro, for your original case - a raw Unix timestamp in the database - the same filter works, because flatpickr understands the U token for timestamps:

$options['dateFormat'] = 'U';
$options['altFormat'] = 'd/m/Y';

The stored timestamp then parses correctly, your visitors see and pick dd/mm/yyyy, and the value is submitted as a timestamp again.

The filter runs for every date field on the page, so if you only want it on one, check $element->settings[‘id’] against your field’s custom ID first.

The built-in separation of display format and return format, the way ACF offers it, is noted internally. I can’t promise a date here, but I understand why it matters for client-facing forms.

Kind regards
Daniele