test.sh fails in some timezones

[sarunint]

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Feature request
[x] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior

I'm living in UTC+7, which makes this test fails:

https://github.com/angular/angular/blob/master/packages/common/test/pipes/date_pipe_spec.ts#L268..L269

Since the specified date in the test is 21st of Jaunary, 2017 in my timezone.

Expected behavior

Some documentation stating that this test is expected to fail in some timezones. Or any other workarounds.

Minimal reproduction of the problem with instructions

1. Set your timezone to UTC+7
2. Run test.sh browser

What is the motivation / use case for changing the behavior?

Environment

Angular version: X.Y.Z


Browser:
- [ ] Chrome (desktop) version XX
- [ ] Chrome (Android) version XX
- [ ] Chrome (iOS) version XX
- [ ] Firefox version XX
- [ ] Safari (desktop) version XX
- [ ] Safari (iOS) version XX
- [ ] IE version XX
- [ ] Edge version XX
 
For Tooling issues:
- Node version: XX  
- Platform:  

Others:

[gkalpak]

I (kind of) fixed a similar issue by changing time to 12.00 in another PR. There are still timezone where it will fail, but are very few. I think it is reasonable to do the same here.

I suspect that using jasmine's mock clock would be a better solution for such cases 😃

[teh-skrud]

I don't think that Jasmine.clock() can be useful here as it only mocks calls to new Date() (i.e. it is used to mock "now"), but we are using new Date(ISOString).

However, why not simply passing an ISOString including a timezone to it ? (i.e. '2017-05-07T22:14:39+0000')
From my understanding, that would still be a valid test to prevent regression for the #9524 bug (@ocombe ?).

EDIT : actually, it doesn't matter as the datePipe outputs a formatted date in the local TZ (it uses Date.prototype.getHours() and similar methods which all are local time dependents). So passing a TZ in the ISOString is of no value (cf the failed test referenced in this issue). So yeah, maybe using 12:00 is the least worst way of solving this.

[ocombe]

Thanks! Will look into it!

[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.}