Format problem in Date component

I hope someone can help me with this.
I’m using the Date component with the format dd-MM-yyyy.
When I enter Sept 6th I see this:
date 1
The calendar shows June 9th.

In a different app I noticed this:
My data source is a Google sheet.
The dates in the sheet have a format dd-MM-yyyy.
The columns in the new table component have the same format: dd-MM-yyyy.
The date components also have that same format.
Yet I see that a date in the sheet 01-10-2021 is presented in Retool as 10-01-2021, both in the table component and in the Date component.
Is this a bug or am I doing something wrong?

When I edit the date component and remove the last “1” in “2021” and then enter the “1” again, then the correct date is shown: 01-10-2021.

And I have a date validation problem and maybe it is related to the problem I described above.
date 2
The second field “dateContractInitExpire” has this custom validation rule:

{{ dateContractStart.value != "" && self.value <= dateContractStart.value ? "See tooltip" : null}}
You can see that the date of that field is after the date of dateContractStart.
However the validation rule results in ‘true’.
Maybe this is related to the other problem?

I hope someone can help me.


1 Like


Could someone please take a look at my problem?
I e-mailed it on Sept 6 to the support e-mail address but since Retool changed its support policy I posted this on this forum.
So it's really important to have a solution soon.
Could someone be so kind to help me?
I would highly appreciate it.

kind regards,

This is odd. I can reproduce it. It seems like the searching (auto-complete) doesn't respect the format. In that format you can type the month first and then it will switch it on enter.

Hey @Reyer_Sneller!

It looks like the auto-complete issue is actually a known bug where the local region settings determine the date input format for auto-complete over the format specified in the component settings. I've added your feedback to the internal tracking ticket we have for it and can let you know here when it's fixed.

As for the validation error would you mind sending over a screenshot of your component settings? Validation seems to work properly at least in this test case:

I'm wondering what configuration I'm missing that would make the issue reproduce.

Hi Kabirdas,

Thanks for the confirmation it's a bug that will be fixed!

Here you will see the screenshot you asked for (in two parts):

The full validation rule is:
{{ dateContractStart.value != "" && self.value <= dateContractStart.value ? "See tooltip" : null}}

kind regards

Hi Kabirdas,

Have you been able to read my last message?
I hope you can give me a hint for a solution.

kind regards

Some additional information regarding the date bug:
In the retool table component and the date component I changed the format in yyyy-MM-dd.
Now a date in my source data (google sheet) like 06-02-2023 (Febr. 6th) is presented as 2023-06-02 (June 2nd).
I was wondering if that is the same problem as the one you wrote before.
But I thought it would be good to report that.

1 Like

Could anybody help me to solve the validation problem?

I'm not able to reproduce the issue in the original screenshot either.

What should a valid dateContractInitExpire date be if
dateContractStart.value = 23-09-2022?

[EDIT] I ask bc there's a bit going on here... I'm thinking the desired logic is

  1. startDate should not be empty
  2. expireDate should be the same or after startDate

is that correct?

A few other thoughts

  • You're comparing date strings; does that render correct results in js (I'm kinda a newbie)? I would think you would use something like
  • Above paired with the short circuit logic could be render interesting results.
  • I think the Custom rule example is awkwardly written. It's written with the inverse logic of the other validation options. If using regex, true = valid, the example is written as true = invalid (not an empty or nullish string)
  • Have you thought about using the disabled property on dateContractInitExpire
    Screenshot 2023-10-25 at 8.47.44 AM
  • Have you seen the Min Date validation option?
    Screenshot 2023-10-25 at 9.59.01 AM

Hi matth,

Thanks for helping me.

The desired logic is

  1. startDate should not be empty
  2. expireDate should be after startDate

Your thought about comparing date strings is an interesting one.
I'm a js newby too.
I will try and follow your suggestion and will let you know the results.


I tested comparing date strings but that works, so that is not the issue.
The strange thing is that when I browse through my table and go to the record with the problem, the custom validation rule does not result in the invalid message.
However when I click the date component and leave that field without changing anything, the invalid message appears.
When I browse to a different record and then move back to the problem record, the invalid message is there immediately.
I tested it in a very small app with only the two fields and then there is no problem at all.
The question is what is the difference between the real app and the test app.
The only difference I see is that in the real app the date compents have a default value from a table component.
Could the problem be related to the known bug that Kabirdas mentioned?

I did some debugging and think I found a cause for the problem.
When I show dateContractStart.value in the invalid-message (after "?" in the custom validation rule) in most cases it is presented in the format yyyy-MM-dd but sometimes in the format dd-MM-yyyy (the formatted value format). And that's why the rule sometimes does not work.
Therefor I suspect that it has to do with the known bug that Kabirdas mentioned.
Could someone from the Retool team confirm this and let me know when the bug has been fixed?
I would appreciate your response.


I can now reproduce the problem with the small app in the json file.
test_date.json (15.0 KB)

The app shows:
• Table1 with 2 rows with 1 column: column1 with format dd-MM-yyyy
• Date component date3 with date format dd-MM-yyyy where the default date is the current row in the table;
• Date component date4 with date format dd-MM-yyyy and with no default value and a custom validation rule: {{ (date3.value != "" && self.value <= date3.value) ? date3.value + " invalid " + self.value : date3.value + " valid " + self.value}}

When you manually enter 22-09-2023 in date3 you will see:
The red dates are correct now and in yyyy-MM-dd format. The date in date4 is later than the date in date 3 so the validation rule evaluates to “valid”.
Now I select the second row in the table.
The date in that row is exactly the same: 23-09-2023.
However the validation rule evaluates to “invalid”.
This is caused by the wrong format of the red date3 value. It is the formatted value (dd-MM-yyyy) and not the value (yyyy-MM-dd).

Without a default value from the table for date3 the custom validation rule works without a problem. So the problem is related to linking the date component to the table.

Could someone from the Retool team respond to this?

Hi @Reyer_Sneller!

Can you try using {{moment(table1.selectedRow.column1, "DD-MM-YYYY")}} for the default value of the date component that's reading from your table?

The value of date components is stored as strings, so it's important that they be in YYYY-MM-DD format otherwise you'll see something like the following be true '01-01-2023 < 02-01-2020' . Passing your dates through the moment library can help with the conversion but moment won't recognize DD-MM-YYYY automatically as a valid date format so you need to pass that explicitly as well (more on parsing dates with moment here).

I've attached an updated copy of your repro app, let me know if that works. And thanks for posting so much of your process around this issue here!
Oct-30-2023 19-19-23

test_date (3).json (12.4 KB)

Hi Kabirdas,

Thanks a lot!
That solves the problem for me.

The remaining issue is what I wrote in my very first message.
There Sept 6th is interpreted as June 9th.
Any idea when that will be fixed?

kind regards

Unfortunately, there isn't a timeline for a fix yet @Reyer_Sneller, but when one is pushed we'll try and let you know here!

Since I cannot wait any longer I changed all dates to the yyyy-MM-dd format and that avoids the problem.
So the bug has not been fixed yet but for me the case can be closed.