[Bug Report] v-date-picker new month is started at the end of previous month in FA-local

MustafaHussaini commented 6 years ago

Steps to reproduce

Versions

Vuetify 0.15.7 and vue2.4

What is expected ?

In date picker month should be started with its first day. which is not working for 'FA' locals.

What is actually happening ?

for current date 26 SEP 2017, correct value in FA local is مهر ۴, ۱۳۹۶ ۴ means 4 in English and مهر is the month 7th in Persian and ۱۳۹۶ means 1396. but in the date picker white space header it is showing ۱۳۹۶ شهریور . شهریور is the month 6 in FA local. on the other hand for blue space it is showing مهر ۴ means 4th day of month 7 which is correct one.

Another problem is date picker table. in codepen month 7 is started at the end of month 6. ۱ or 1 in English is the first day of month 7 in FA local which should be in the first row of table but now it is on the last row after ۳۱ or 31 of month 6 in FA local.

Reproduction Link

https://codepen.io/MUHU/pen/QqdVLP

nekosaur commented 6 years ago

@jacekkarczmarczyk Is this fixed with VDatePicker refactor?

jacekkarczmarczyk commented 6 years ago

No, that's a completely different issue

miladmeidanshahi commented 6 years ago

it's so important to be fix

mhf-ir commented 5 years ago

Wrong date time showing, It's actually a bug not an enhancement, i hope it's fix soon.

amirhoseinsalimi commented 5 years ago

Same issue here... Can't be used in a production level web app!

mhf-ir commented 5 years ago

Quasar already implemented: https://codepen.io/rstoenescu/pen/wOGpZg

mhf-ir commented 5 years ago

As i mentioned we need aggregate cldr data for get correct date time information base on locale: https://github.com/vuetifyjs/vuetify/issues/6881

Best date time picker approach is many countries has multiple calendar system and fortunately Intl.Datetime format is good.

I think best approach for date time picker will be good if:

Remove hard coded parts use variable base on locales, use CLDR.
Component data must be Date object not an string, sees both Vuetify and Quasar Dont use this method, String manipulation is not great.

// bad practices:
new Vue({
  el: "#app",
  data: () => ({
    picker: '2018-06-17'
  })
})

// good one
new Vue({
  el: "#app",
  data: () => ({
    picker: new Date(),
  })
})

:1st_place_medal: Notice If you work as backend developer consider clients always send UnixTimeStamp and you always send UnixtTimeStamp though. It's hard this process to carry on backend, browser knows about intl and client timezone lets client process this one.

Date only data is not valid cause of timezone different, date depened of client timezone Maybe you send order from USA at '2019/01/01' but consider witch time and which timezone, Users in india might see as their local time as result of order so Date only it's not valid. so it's always came with time and timezone, Using UTC solved the problem via time.

Notice For date only we can use UTC 12:00:00 not 00:00:00 or 23:59:59 for timezone diff.

Date time picker must support multiple calendar system, primary and secondaries are optional https://github.com/unicode-cldr/cldr-core/blob/master/supplemental/calendarPreferenceData.json

Sample for FA-IR:

Screenshot from 2019-03-31 21-43-48

I could help with this algorithm for process but i'm not Vuejs or Vuetify expert.

Conclusion:

Remove hard coded parts
Use CLDR (aggregated just needed info)
Use Date object instead of string
Multiple calendar systems

mhf-ir commented 4 years ago

https://moment.github.io/luxon/docs/ might be good tools for i18n date time

curiousyigit commented 4 years ago

OMG it's been 2 years and this is not fixed yet! This problem also exists in the 'ar-sa' locale.

phtyrant commented 4 years ago

same problem... hope they fix this issue

amirhoseinsalimi commented 4 years ago

I'm using vue-persian-datetime-picker component for the Jalali calendar and I'm happy with it; It supports both Jalali and Gregorian calendars with an easy API. Give it a try and if you want to deploy it as an inline date picker check this issue out, solved by the author.

johnleider commented 4 years ago

@jacekkarczmarczyk Any update on this?

jacekkarczmarczyk commented 4 years ago

That would require a big refactor of the internals. There's also a question how do we treat the model. If it's a ISO date string then I don't see how we should implement a month picker where the model is never an ISO date as it spans over 2 months. If we treat it as a string what should be the behaviour when the calendar is switched from persian to other one (for example in some multilang app)? Should it automatically change? Should the dev be responsible for converting the persian string to ISO when saving value in database? So many questions so few answers

vahidForughi commented 4 years ago

I have the same problem, we have a big problem in persian when we want use every date packages. we should search and find version which support Jalali . for example when use moment we should import moment-jalali too. so you can just add is-jalali prop in calendar and datepicker component. we don't want put or get converted date or etc. just correct displaying is enough.

Al00X commented 4 years ago

I agree that fixing the display is enough. It's been years since this problem issued. I really appreciate if this problem gets fixed soon.

artmarydotir commented 3 years ago

Any plan for fixing this in vuetify roadmap ? will it be fix at v3.0 (Titan) ?

@jacekkarczmarczyk

johnleider commented 3 years ago

After talking with the team, we haven't been able to nail this one down. I'm moving this to the Vuetify 3 project so that we can re-evaluate it once we get to Phase 3 of the development process (The one where we put v-date-picker together), to see if it can happen naturally or at least have some sort of path forward.

Once we get to that point I will update this thread and see what options we have available. Thank you for your patience.

If you have any questions, please reach out to us in our Discord community.

momtazmohammad commented 3 years ago

Any plan to fix this issue , long time it's open many thanks in advance

artmarydotir commented 3 years ago

Any plan to fix this issue , long time it's open many thanks in advance

v3

MustafaHussaini commented 3 years ago

So far, I opened this issue, I think I should contrbuite and solve this issue ASAP.

jacekkarczmarczyk commented 3 years ago

@MustafaHussaini do you have some idea how it should behave when you have set month to 2020-01 in en locale and then you switch to fa?

edit: in month picker

MustafaHussaini commented 3 years ago

When we switch to fa local, If there is no day specified in date string just (2020-01) then we will convert firt day of month (2020-1-1) to persian which is (1399-10-11). then the selected month in FA will be 10. Did you got it?

mhf-ir commented 3 years ago

@jacekkarczmarczyk @johnleider, simple implentation using https://github.com/moment/luxon:

All input will be JavaScript Date not the stupid string
- User might use different calendar but how to store or process then when multiple calendar? You always set standard Date in your database or etc. Database dosnt support special calendar process.
- You can convert Date to any calendar and locale base.
Using CLDR json for get required info (https://github.com/vuetifyjs/vuetify/issues/6881)
Many Calendars, Many Countries, Many Locales

I said before input string is not valid approach. Most of date time pickers use this way, and it's wrong.

Open with latest Desktop chrome or latest Nightly firefox (Problem is for DisplayName)

polyfills added for older browser Demo: https://github.com/mhf-ir/test-gha https://mhf-ir.github.io/test-gha/test.html

Older version using moment : https://github.com/artmarydotir/aasaam-vuetify-datetime https://github.com/aasaam/date-time

Hamedamz commented 3 years ago

Any updates? @jacekkarczmarczyk

m-farahmand commented 2 years ago

+1

hamedf62 commented 2 years ago

the problem still annoying. please alter it.

mahozad commented 8 months ago

@johnleider I think a dozen related issues were marked as duplicate and were referred and redirected here but all or most of the problems still remain as of version 3.4.8 of the library.

These bugs and problems are for Jalali/Solar/Persian calendar used for Persian/Farsi (fa) locale in Vuetify.

Were they fixed? Can I help?

The "month year" label should be reversed for RTL locales (e.g. instead of "‏۱۴۰۲ دی" it should be "دی ۱۴۰۲") This is probably because month and year have been simply concatenated (which is fine in LTR scripts). So, the fix would probably be to make month and year label two components/divs/whatever and applying locale layout direction to their parent (button)
The previous/next month buttons are in reverse order (I think this can also be fixed by applying locale layout direction to the parent)
The month labels in the month selection section are off by one (it means the default selected month is one less than what it should be)
The year labels in the year selection section are off by one (one less than what they should by)
The following problems are less serious:
- The days in the picker do not start from 1 (they start from 9 or 10 or 11)
- The months in the month selection section (which can be opened by clicking on the "month year" button) are not in the proper order (starts with دی but should start with فروردین)

By the way, I was surprised when I saw Vuetify supports Jalali/Solar calendar. Thank you for that.

johnleider commented 8 months ago

This bug is related to an earlier version of Vuetify. If this is still present in v3 of the framework, please create a new issue. Thank you!

vuetifyjs / vuetify