This repository has been archived by the owner on May 29, 2019. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi,
I had a problem with timezones the other day at work and realised that other people have this problem and although it can be fixed outside of the framework I feel like it really should be part of it.
Basically if at any time the datepicker (or datepicker popup) is set to undefined/null -which they may be to represent no date has been chosen-, the previous code would result in a
Date
object with 0 as it's time but the timezone of the computer. This results in an incorrect UTC time which can cause problems for anyone trying to use the directive across multiple time zones (like we do at work).This change should mean that if a date already exists it's timezone is used, but if there isn't the current time and timezone of the computer will be used instead.
Technically the whole left hand side could be replaced with just
new Date
, but I understand there may be a possibility that someone may be depending on the fact that the time component is always the same if the user switches between dates.This change shouldn't really break anything since any users who were relying on this part (like we were at work) have either not discovered the problem or fixed it in their own codebase, either way this shouldn't really their current implementations.
Hope this helps :)
Thanks,
Mohamed