Time zone problems

[fidian]

I am having a hard time using this plugin because I am not in UTC. In validateDate one makes a new Date object. Mine looks like this in my console:

new Date(Date.UTC(2005, 8, 12))
Sun Sep 11 2005 19:00:00 GMT-0500 (CDT)

This date does not validate because of the following check: d.getDate() === Number(date.day)

d.getDate()
11

I passed in the day of 12 and because I live in CST, the date now appears to be 11.

[rorymadden]

Hi Tyler,

I can't look into this today but I'll have a look at the weekend. I don't
use this module myself anymore because each time I wanted to show a date I
needed a separate format (year drop-down, year text field, date range
etc.). I pulled out the calculation logic as a separate service though as
that was constant.

The service does the date checking and provides the reference data. There
is a dependency on the pascalprecht.translate module as I have chosen to
show the month names (which are different in every language) but I could
update this easily to just show the month number. I will release the
service as a separate module and you can use the template in the directive
for your page.

I will have a look at the UTC issue. I live in Ireland so I am at UTC time
but my intention was to store the date as the user entered it. I might have
to update my computer clock to fake timezone changes to do some testing.

Cheers,
Rory

On 12 March 2014 23:12, Tyler Akins notifications@github.com wrote:

I am having a hard time using this plugin because I am not in UTC. In
validateDate one makes a new Date object. Mine looks like this in my
console:

new Date(Date.UTC(2005, 8, 12))
Sun Sep 11 2005 19:00:00 GMT-0500 (CDT)

This date does not validate because of the following check: d.getDate()
=== Number(date.day)

d.getDate()
11

I passed in the day of 12 and because I live in CST, the date now appears
to be 11.

Reply to this email directly or view it on GitHubhttps://github.com//issues/3
.

[vikrama]

new Date(date.year, date.month, date.day) should do

[gareththackeray]

vikrama is correct about this. Just forget the Date.UTC bit as JS always converts every date to local so you just end up with a non-midnight time in any other timezone which then needs to be converted back to UTC to actually get the midnight time (and correct date, if you are in a negative offset timezone).

This obviously could be a breaking change but it requires significant more work to use as is than with vikrama's fix I'll submit the pull request.