Open andrewplummer opened 3 years ago
(ie. if you were to mock Date.prototype.getTimezoneOffset and then call FakeTimers.install your mock would be shadowed and inaccessible).
Why is that - the source code indicates this should work https://github.com/sinonjs/fake-timers/blob/master/src/fake-timers-src.js#L181
Ah I stand corrected! That does appear to work. Well in that case I suppose the only reason is that a clock.setSystemTimezoneOffset
might be a useful addition since sinon has already gone to the trouble to create a nice API to mock Date
. It's not as compelling an argument as I originally thought though so feel free to close.
Thanks for a great library!
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
@andrewplummer If you want to see this happening the source code is quite readable and easy to grok, so I think a PR could be whipped up in less than an hour :wink:
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
It would be very nice to have a way to mock the system timezone offset, ie. override
Date.prototype.getTimezoneOffset
.I realize that this is possible and not very hard without
fake-timers
, however given that it hijacks the globalDate
object, if you were to do this the order of applying the mocks would then become a consideration (ie. if you were to mockDate.prototype.getTimezoneOffset
and then callFakeTimers.install
your mock would be shadowed and inaccessible).I realize that this package is doing a lot and timezones aren't really its main intent, but since it is mocking the
Date
object it makes sense to me that mocking this method also could/should be something that it does.