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).