Datepicker: Incorrect date displayed when selecting a date in the first week of November 1999

[willisd2]

Bug, feature request, or proposal:

Bug

What is the expected behavior?

When selecting November, 4, 1999 from the datepicker, the input will display 11/04/1999

What is the current behavior?

When selecting November, 4, 1999 from the datepicker the input displays 1 day behind, 11/03/1999

What are the steps to reproduce?

Select November 4, 1999 from the datepicker in the supplied plunkr:
http://plnkr.co/edit/4kiAVKRyskrJFxHNZLuy

What is the use-case or motivation for changing an existing behavior?

It's a bug, the existing behavior is unintended

Which versions of Angular, Material, OS, TypeScript, browsers are affected?

Not sure, just something I noticed on the Material documentation site. I'm using Chrome 58.0.3029.110 as my browser

Is there anything else we should know?

This happens for the first week of November in both 1999 and 2000, likely other places as well.

[julianobrasil]

Seems to be working fine:

[willisd2]

Interesting, might be a locale issue.

[julianobrasil]

I forked your plunker and added some locale settings. Try it with your language (don't forget to fix the myParse function): http://plnkr.co/edit/xfab14?p=preview

[willisd2]

Hmm, I'm still getting the same behavior, in Chrome and Firefox. What needs to be fixed in the myParse function?
Also, FWIW I tried it in Microsoft Edge 38.14393.0.0 and I get the expected behavior.

[julianobrasil]

myParse function is configured to brazilian portuguese, which uses the day/month/year format. If the format of your language is similar, you have to do nothing.

Intriguing behavior you're experiencing...

[julianobrasil]

It happens here. I picked a date way before 1999.

[julianobrasil]

It's a problem with Daylight Saving Time. The datepicker builds a javascript Date object with the date you picked and set the time to 0:0:0 (in fact, javascript does it when you build a Date object providing just year, month and day).
You can get more details in here: https://stackoverflow.com/a/5860841/6433166

You can solve it overriding the createDate function of the NativeDateAdapter and setting the hours to 12, instead of leaving it to 0:0:0 (midnight).

Take a look at this plunker where I made the little change shown below: http://plnkr.co/edit/shFewF?p=preview

createDate(year: number, month: number, date: number): Date {
    
    if (month < 0 || month > 11 || date < 1) {
      return null;
    }

    let result = this._createDateWithOverflow(year, month, date);
    result.setHours(12); // <- here is what corrects it

    if (result.getMonth() != month) {
      return null;
    }

    return result;
  }

@fxck , please, take a look at this... is my conclusion right? I mean... is this the right place to do it? Or is it something that should be fixed with a more complex code somewhere else in order to preserve the midnight time in the Date object?

[mmalerba]

Interesting, I'm not seeing this for 11/4/1999 or 11/6/1984, I wonder if it only happens depending on the time zone you're in or something.

edit: ah, I've managed to repro for 8/14/1800, will investigate

[julianobrasil]

@mmalerba, I think the problem hapens when you try to access a date contained in Daylight Summer Time in your locale zone.

[julianobrasil]

The problem seems to affect some past dates, according to what is writen in ECMA 5.1 specification:

The implementation of ECMAScript should not try to determine whether the exact time was subject to daylight saving time, but just whether daylight saving time would have been in effect if the current daylight saving time algorithm had been used at the time. This avoids complications such as taking into account the years that the locale observed daylight saving time year round.

Basically it seems that it'll calculate past DST dates as they had happened nowadays. Then we have a problem when the DST in the past doesn't follow today's rule (It happened in Brazil in the year of 1984)

[mmalerba]

@julianobrasil Ah yeah that sounds like it may be the issue, I wonder if I can try converting to UTC dates or something to get around this. I'd like to avoid setting hours since it'll complicate things later when I add a timepicker

[julianobrasil]

@mmalerba, I tried it with UTC dates and have good news: http://plnkr.co/edit/jc4Ywu?p=preview

This time, I'm not messing with the hours. I think it's working just fine even considering the problematic past DST dates like Brazil's November 7th, 1984 (from 1980 to 1984 we didn't have the usual October-to-February daylight saving time period over here):

I also tried some other timezones (changing my notebook timezone) that are critical from my point of view (GMT:0, GMT:+1200 and GMT:-1200) during standard time and DST. It was not an exhaustive testing series, but it worked with all cases I tested. Also tested with GMT:-0500 (as it seems to be the timezone @willisd2 had the problem)

Edited: But this aproach is not different from setting the hour manually (except for the fact that you can possibly set the hours by a time piker in the future - but in this situation you should take care of the DST again if you wish to avoid the problem. Or... work with UTC dates everywhere in the component, abandoning the Date object - it is a tricky issue, I think).

[jimitndiaye]

I'm seeing the behavior with 10/26/1982 - menu displays correct date but value is 10/25/1982. Time zone is BST.

[julianobrasil]

@jimitndiaye, did you tested that date with my plunker? I tried here setting to UTC+01:00 in my notebook (which I think is BST - correct me if I'm wrong) and it worked fine with 10/26/1982.

If you didn't try my plunker, please, give it a try (it's in Brazilian Date Format: dd/MM/yyyy) and let me know if it doesn't work: http://plnkr.co/edit/jc4Ywu?p=preview

[jimitndiaye]

@julianobrasil Works fine with your plunker. I originally tried it on the demo site: https://material.angular.io/components/datepicker/examples

[functionportal]

This is what happens for ISO date "1948-11-02T04:00:00.000Z"

[julianobrasil]

@craftyInstigator, There is a PR to fix it. If you can't wait, try this solution: http://plnkr.co/edit/jc4Ywu?p=preview

[murilobd]

Hey @julianobrasil I'm facing the same issue right now! It's 17th October 17:54 (GMT-02 because of daylight summer time) right now and when I select a date on DatePicker (using the CustomDateAdapter from http://plnkr.co/edit/jc4Ywu?p=preview) I'm getting the next day (18th October).
I've tried a bunch of other configurations, changing hours, trying with UTC but didn't manage to make it work correctly. Any idea what else I could do?

[julianobrasil]

@murilobd, aparently there's an issue with datepicker and DST in some regions. This seems to be related to Javascript Date object and ECMA 5.1 - so it depends on the browser you're using. Take a look at #7167 (comment).

[murilobd]

Got it @julianobrasil ! Thanks for answering!! Last question: how complicated would be to use moment.js as DateAdapter!? Maybe they already have fixed this issue!

[julianobrasil]

Yeah, in moment.js dateadapter this issue is not happening. I've never used it, but if I had problems, I'd use for sure! It doesn't seem a complicated thing. Aparently you'll just have to switch your project Dates to Moment object.

[murilobd]

Thanks @julianobrasil !! I just created a gist with the MomentDateAdapter I've created for build beta 8 from Angular. If anyone needs: https://gist.github.com/murilobd/605edbc5c668f4f9f943dfb82a7cadd9

[julianobrasil]

@murilobd, currently there is an official MomentDateAdapter (that accidentaly wasn't included in beta.12): https://github.com/angular/material2-moment-adapter-builds

[murilobd]

@julianobrasil yeap! I found this MomentDatePicker and used! As my application is running on Beta 8, I had to change some code to make it work!

[rahimnagori]

This issue only appears if your current timezone is below 00:00 (negative).

[julianobrasil]

@rahimnagori, this shouldn't be an issue anymore since #10068, that was merged last year. Have you seen it happen recently?

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}