Wikiki/bulma-calendar

Separate presented date (and probably time) format from the actual value of the input

dmcbrn opened this issue · 4 comments

dmcbrn commented

I'll be talking about the date input as I haven't used the time one yet.

Currently we can change the format of the date using dataFormat attribute. For example we can set it to yyyy-MM-dd.

  1. In the documentation it says the default is (I didn't check what's in the code though) MM/DD/YYYY but when I try to set it to YYYY-MM-DD or MM/DD/YYYY I get the warning to lower the case of YYYY and DD. So, no biggie as it's straightforward to fix, just logging.

  2. What I'd like is to have separate format presented in the input field from the one actually used as the input's value. For example I'd like to present the date as 31.12.2021. but actually send the 2021-12-31 to my backend. I assume most of the backend libraries like Carbon can parse both of these formats but I'd like to avoid possible issues here by standardizing the passed value. Also, some characters like / are preceded with \ in url and it looks ugly when shared.

michael-hack commented

  1. This documentation is obsolete, the mentioned parameters are still from date-fns 1.x and now we use version 2.x, as a result of which MM/DD/YYYY became MM/dd/yyyy. I have only unfortunately no possibility to change the old documentation, the current one can be found at the following link: https://doc.mh-s.de/bulma-calendar/

  2. That's a big point I've been thinking about for a long time. The HTML standard provides the format "yyyy-mm-DD" for the date field and at the moment we deviate from this because we follow the configured format. I think it would make sense to keep the output basically only in the HTML standard, the formatting is then only for display.

What do you think?

dmcbrn commented
  1. Oh yes, not sure how I ended up there as the link on this repo clearly posts to the link you provided. Google probably.
  2. Yes that makes perfect sense. Keep in mind this might introduce breaking changes to people already using library in production.
michael-hack commented

I am aware of this and that's the reason why I have not moved on... But I think that will change soon.
I will close the issue, because there is already another one for this.

dmcbrn commented

You could move on to v7? it is not huge upgrade and it should go under patch but it will not break people apps and in the end that should be more important. Anyhow, can you give me a link to the duplicate issue so I can subscribe, if you have it handy?