Date format differences

amoss

Hi

Quasar is working with date format of ‘YYYY-MM-DD’ (all uppercase). When setting a date format of ‘yyyy-MM-dd’, the year and day are not showing correctly.

Syncfusion accepts ‘yyyy-MM-dd’ and when setting ‘YYYY-MM-DD’, the year and day are not showing correctly.

Java also works with ‘yyyy-MM-dd’ so I wonder why quasar took a different direction while my main question is, how can I bypass this contradiction except for storing 2 kinds of date formats

Thanks

s.molinari

Isn’t the final result that is important, isn’t it? I’m confused as to the issue here. Can you explain what “not showing correctly” means or what exactly the contradiction is?

Scott

amoss

quasar with yyyy-MM-dd shows YYYY-04-DD
quasar with YYYY-MM-DD shows 2020-04-16

syncfusion with YYYY-MM-DD shows YYYY-04-DD
syncfusion with yyyy-MM-dd shows 2020-04-16

s.molinari

So, if you are formatting, you just need the right formatting string. Right? It has nothing to do with the value(string) given representing the final date, does it? I mean, formatting shouldn’t be changing the core value of the date, right? It’s just for view output?

Scott

amoss

I want to format a date with yyyy-MM-dd meaning 4 digits year a dash 2 digits month a dash 2 digits day, for example: 2020-04-16.
Because of the how quasar expects its format string (YYYY-MM-DD) which is different than the standard I know of, I can’t do that.

s.molinari

But, YYYY-MM-DD gives you 2020-04-16, which is the final format you need, right?

I’m sorry I’m being so dense. Maybe explain the code challenge itself?

Scott

metalsadman

@amoss the quasar date util tokens are here https://quasar.dev/quasar-utils/date-utils#Format-for-display.
seeing sync’s https://help.syncfusion.com/js/datepicker/display-format. i don’t see the problem? obviously comparing both formatting yyyy sync = YYYY in quasar util so just use the caps. meanwhile the d's and M's are the same. quasar date util tokens are even more comprehensive than syncfusions -.-. so i dunno where’s the confusion here @.@

amoss

I’ll try to simplify
If I parse today using YYYY - quasar shows 2020, sync shows YYYY
If I parse today using yyyy - quasar shows yyyy, sync shows 2020

Is it clearer now?

metalsadman

eh? why are you combining the 2? obviously they use different tokens in years, maybe make a codepen from where you are using quasar date util. or simply enough, since you are the one who has control over it, then you can just have a condition if it’s quasar caps(toUpperCase) the year part of your date string token or toLowerCase if sync.

amoss

I wrote IF I parse… meaning I’m not combining the 2.
I set a default date format YYYY-MM-DD and work with that all over the app. With quasar it was ok and all is fine.

I started using syncfusion components and I noticed that the same format shows YYYY-04-DD instead of 2020-04-16.

I went back to the default format and changed it to yyyy-MM-dd to see what happens. I then saw syncfusion correctly show dates but quasar date utils started showing yyyy-04-dd instead of the date.

I know that yyyy-MM-dd is standard, even Java is using it, I never saw YYYY and DD elsewhere. so I wonder if quasar could work with this standard as well.

Is it clearer now?

Allan-EN-GB

There’s no point going around in circles on this - it would be a huge breaking change so it’s not changing.

You’ll have to work around it.

For more information about the standard we’re using: https://www.iso.org/iso-8601-date-and-time-format.html

amoss

I’m not talking about breaking anything, I’m talking about YYYY-MM-DD to behave as yyyy-MM-dd. Meaning if the format I send is yyyy-MM-dd then it will behave as if I sent it YYYY-MM-DD. I might be wrong but a format = format.toUpperCase() in the beginning of the function might do the trick.

Again, I might be wrong.

qyloxe

@amoss said in Date format differences:

Again, I might be wrong.

yep, both of you and syncfusion (as it seems) are on the wrong side this time
Standards DO matter, please read this article:
https://en.wikipedia.org/wiki/ISO_8601
If your syncfusion layer is not compatible with ISO then you should put the matter with them.
Quasar - working on the library/framework layer, is on the right side with date formatting.

If you want to integrate two frameworks/libraries, then remember that you are doing this by your application layer. Hence every conversion/translation is your responsibility and not said library/framework.

In this situation, exchanging incompatible data depends on mutual agreement of the partners exchanging information - in your case it is your application.

This also rises somewhat unpleasant question: if syncfusion is not conformant to this one ISO standard, then where are the other surprises/shortcuts in this syncfusion? Is it a right decision to use such a library/framework?

As a user of Quasar framework I am really happy that it keeps with ISO standards and would not expect nothing else.

amoss

I come from Java and they are using the same yyyy-MM-dd format. The following is taken from https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html where LocalDate is their latest and recommended to use class to handle date and time (instead of Date and Calendar).

  LocalDate date = LocalDate.now();
  DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy MM dd");
  String text = date.format(formatter);
  LocalDate parsedDate = LocalDate.parse(text, formatter);

Anyway, I understand the need of using the YYYY-MM-DD standard, all I’m saying is “why not both”?

qyloxe

@amoss said in Date format differences:

Anyway, I understand the need of using the YYYY-MM-DD standard, all I’m saying is “why not both”?

why not three? ten? hundred?

I can only repeat - conversions/transformations between frameworks is your responsibility at the application layer. I assume, that it is you who extracts data from one place and loads it into another. If yes then transform phase between extract and load is your job. This is so called ETL.

why not “weaken” standards and put here and there some exceptions or special cases? Because then you will not have standards but so called “conventions”. There are many standards which over years became just “conventions”. For example ldap/active directory. The idea of catalog services is neat, BUT over years, too many people agreed to “just a little helper here and there” and now, if you want to do anything with ldap/ad, you need to learn all those conventions put into this “standard” for all those years. It is madness.

So: enforce the standards, keep your code clean, do not mix layers, look on the bigger picture. And this is the road to IT happiness

amoss

@qyloxe said in Date format differences:

I assume, that it is you who extracts data from one place and loads it into another. If yes then transform phase between extract and load is your job. This is so called ETL.

So I will repeat as well, I don’t ETL anything, I don’t extract anything, I don’t load anything and I don’t transform anything from one place to another. I simply want to show a date on screen.

date.formatDate(new Date(), 'yyyy-MM-dd');

qyloxe

@amoss said in Date format differences:

date.formatDate(new Date(), 'yyyy-MM-dd');

ok, lets play (in the context of Quasar):

why did you mentioned syncfusion if it is only what you want?
where comes this string ‘yyyy-MM-dd’ from? it is not conformant with Quasar documentation.
if you accept to use this non ISO format string, then why can’t you keep this format in some kind of constant string in your app parameters, or even have your own, app specific conversion function from ‘yyy…’ to ‘YYY…’ - lets say - convertFromMyAppDateFormatToISOFormat(str)?
why do you think that breaking ISO conformance at the framework level is a “good thing” - in a big picture? You realize, that case of format letters in ISO 8601 is meaningful?

amoss

Because as I wrote, I started with YYYY-MM-DD and all was well until I started using syncfusion’s library and that didn’t work.
Obviously, I don’t put yyyy-MM-dd or YYYY-MM-DD directly, I use the user’s date format as he selected in the settings. this.user.settings.dateFormat. It could also be DD/MM/YYYY and MM/DD/YYYY.
See point 2.
I come from Java, and there I use yyyy-MM-dd, for all I know, this is the standard from a long time ago.

Allan-EN-GB

@amoss You coming from Java and Java / Syncfusion doing what they do has no correlation to us adhering to standards.

Just because a language decides to do something, it doesn’t make it a standard.

Hypothetical scenario: 2 years down the line, ISO_8601 adds something so that yyyy (lowercase) does something different. Where would we stand then, because by your request we’ve upper cased it. There is a reason frameworks use and stick to standards.

It’s not changing - let’s leave it there

No More Posting New Topics!

Date format differences