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

[nanov]

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.

[pdanpdan]

The problem with YYYY-MM-DD is that the browser treat it (in some implementations) as date in local timezone and you'll get different dates in different timezones.
YYYY/MM/DD is always treated as date in UTC timezone.

https://stackoverflow.com/questions/30199130/different-result-for-yyyy-mm-dd-and-yyyy-mm-dd-in-javascript-when-passed-to-new

[nanov]

From the linked issue it seems to be exactly the opposite, YYYY-MM-DD is treated as UTC ( and adjusted to local ) and YYYY/MM/DD is treated as local ( and therefore not adjusted ).

Timezone handling is something that the user needs to take care of before passing the date to the components, as with both formats there are "specifics" he needs to take care of.

EDIT
Just pasting the comment on the accepted answer from your link.

Like I mentioned in my own answer this is only partial right: "2015/03/31" is not a supported date string according to ECMA. Therefore it's up to the JS implemetation to decide what to do with it. Many browsers parse it as a date in the local timezone, but they don't have to. E.g. Safari returns NaN

This makes my point event more valid.

[pdanpdan]

Sorry, I might have put it in reverse. Check this: https://github.com/quasarframework/quasar/issues/2658

[nanov]

I did a (POC) pull request implementing my suggestion, as all the dates are handled as in the same timezone ( ie not string parsing of dates is done directly as new Date('2019/02/02')) I really don't get point of using a not-standard format.

Additionally the an emit-object ( or similar ) flag could be added to the QDate component which would make it emit something like this: { year: 2012, month: 5, date: 15 } and will allow one to work further with common date utils.

[stefanvanherwijnen]

I agree that the ISO standard should be followed (i.e. YYYY-MM-DD).However, if JavaScript date messes up the interpretation of the dates in such a format, I see why a different format was chosen.
If I understand correctly from this article: https://jj09.net/javascript-date-a-bad-part/ , it is advised to use MomentJS in order to prevent problems with Date.

Maybe some MomentJS-like functionality should eventually be integrated in Quasar in order to fix the whole mess with JS Dates?

[nanov]

(limited) MomentJS ( like ) functionality is integrated inside date utils.

As of for the current discussion, I don't really see the problem, as the date is passed as string, and emitted as one. Inside the date is never constructed from the string directly ( ie. the UTC conversation problem is somehow avoided ), but rather from the different parts.

The only problem that may occur is when one directly uses the emitted value into the Date constructor.

[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

[natxocc]

For my part, I prefer to have YYYY-MM-DD. It's better for work with dates not only in different languages using JS utils nor working in other systems like MySQL and other ISO standards.

[stefanvanherwijnen]

Maybe a parse() function should be added to the Date Utils. As I see it, the problems start when a JS Date comes into the game. So even if the whole app uses date strings, the moment you want to manipulate a date (and thus having to create a JS Date), the problems start with timezones etc.
In that case the format of the strings can be converted to anything, and if someone wants to use the actual date for processing they would parse it with the date util.

[robsoncombr]

I consider this a break from previous version that had this solution in 'format'. There are people from different countries that use different formats in different time zones and do not use SSR. I'm adding my +1 as interested on this format solution for this component.

[robsoncombr]

I have created a temporary work around to format DatePicker, currently it is using DD/MM/YYYY format but can be changed to any other. Hope it helps. https://github.com/controledigital/quasar-solutions/blob/master/components/cInputDate.vue

[rstoenescu]

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