I'm currently wondering a bit about date fields... 1. The fields can be formatted with Luxon tokens. I seriously never heard of these and wonder why you didn't choose strftime, which is the same as Rails uses, or why you are not reusing rails localize method? (https://www.bairesdev.com/tools/strftime/) 2. When using the luxon token

cccc

, which should give the day of the week like

Wednesday

, this is not translated into my locale, but will always be english... 3. I could work around this by using

format_display_using

, but this does not seem to exist for this field type? 4. I wonder if we could have an option to disable flatpickr on desktop, too, as I'd prefer the native date pickers there (native datetime pickers are another story, firefox still only has a very basic one, but the date pickers are all right). They are also more accessible and work natively when testing with capybara.

Thread automatically created by Tim in #1141725718364045394

Just passing

format: :short

, which then uses the date formats from my locale files, would be absolutely perfect 😇

Hey Tim, Let me try to respond. On our channel, @loud-jewelry-99127 Asked the same thing. "Why did we use a JS library instead of Ruby's default" 1. The show and Index views of the date and date_time fields are not plain text. they take that value of the time which is (probably) stored in UTC and converts it into the browser local timezone. We need JS to do that and luxon was one of the most popular and well supported time libraries of the time. TBH I still think it's popular in the JS ecosystem. Nowadays I think we got some new JS native way of doing that, which is great. 2. I'll ask @loud-jewelry-99127 to look that up. I don't know if we included all the locales and if that's easy to do, or better yet, enable you to add them selectively. 3. If you really want to use

format_display_using

I'd go for two fields. One visible on forms as the date/date_time and another

text

on display fields (index & show). This way you get full control over how you display it. 4. If you got this far, I'd recommend you create a new custom field. That way you get full control over every view, formatting, and display. You can even add a

format

option that takes

strftime

or other values you need. I know.

date

and

date_time

fields look overengineered. They are a big pain in our behind too, tough to test, and generally on the heavy side, but they do do the time localization very very well. Some (me included) like flatpickr more than the browser one.

Thanks for the quick response, as always ⚡ I get the reasoning with the timezones (even though it should be irrelevant for actual dates without a time). Regarding point 2 - my locale is german, so a "rather popular one", I'd guess 😅 Maybe it's just not implemented at all. I might try the custom field option, thanks for pointing that out! I'm in the lucky position that we always handle timezones as germany-based, so we do not have an issue here 😉

Lol. You’re totally true regarding the time zones and dates. I think it was a case for making the fields inherit from each other (formatting tokens and such)

That was quick, thank you! The localization helps a lot 🙂