[v1] Discussion: Default date format ( YYYY/MM/DD ).

Background In v1, as opposed to previous versioning, everything that handles dates does not receive a format option, but rather forces you to comply with a default one.

Problem The choice of the default date format is YYYY/MM/DD, which, at first glance, seems a rather strange decision as it does not comply with any standard.

The de-facto standard, ISO compliant date format is YYYY-MM-DD which seems a far better choice than the current one, which is also widely implemented in various REST apis, and part of the JSON-Schema standard formats.

Proposition I would purpose to switch to this format as the default one. The sooner this is done ( before v1 is widely adopted/ out of beta ) it will eliminate the need to write multi-format/format-adjusting logic into components dealing with those and keep things simple.

[rstoenescu]

Optional mask and locale will be available in beta.24 for QDate.

[rstoenescu]

Hi, Won’t get into too many details, so this is a high-level overview:

Up to 1.0 we were using the Quasar date utils, which is that “momentjs-like” functionality. It’s good, but beginners can easily mess things up due to the buggy native JS Date object.

We also wanted faster rendering (so avoid parsing and reparsing JS Date objects), and also avoid problems when using SSR. In 0.17 the date component was rendered only on client side because otherwise there would appear hydration errors (time on server may be different than time on client). We wanted (and succeeded) in avoiding all this mess with the native JS Date object by using a String as model only.

The recommended way when instantiating a native JS Date object is to use “/” as separator instead of “-” to avoid the timezone issue. But this doesn’t matter anymore for v1.0.

We got a big pile of work items still needed to be solved before we can take a decision regarding the format (together with you, the developers using Quasar), so please hold on until it comes the turn for this.

Thank you, -Razvan