reinstate clock service

[pamapa]

I dropped the clock service when migrating to Typescript. Thought it was only used because of unit-testing, which is not the case. This MR ports that functionality in the same way as the legacy library. I make the getEpochTime in the ClockService return a none promise. As the Timer now uses getEpochTime from ClockService, but there are other modules which need an unchangeable getEpochTime function too i have added a DateUtils class.

Closes/fixes #414

Checklist

• [ ] This PR makes changes to the public API
• [x] I have included links for closing relevant issue numbers

[codecov[bot]]

Codecov Report

Merging #416 (50ef93b) into main (707435f) will increase coverage by 0.04%. The diff coverage is 88.67%.

:exclamation: Current head 50ef93b differs from pull request most recent head 99ba5c8. Consider uploading reports for the commit 99ba5c8 to get more accurate results

@@            Coverage Diff             @@
##             main     #416      +/-   ##
==========================================
+ Coverage   75.25%   75.30%   +0.04%     
==========================================
  Files          44       45       +1     
  Lines        1572     1583      +11     
  Branches      288      290       +2     
==========================================
+ Hits         1183     1192       +9     
+ Misses        363      362       -1     
- Partials       26       29       +3     

Flag	Coverage Δ
unittests	75.30% <88.67%> (+0.04%)	:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
src/SigninRequest.ts	100.00% <ø> (ø)
src/index.ts	100.00% <ø> (ø)
src/User.ts	69.23% <50.00%> (+1.23%)	:arrow_up:
src/UserManager.ts	54.50% <66.66%> (ø)
src/State.ts	85.29% <84.61%> (+0.44%)	:arrow_up:
src/AccessTokenEvents.ts	90.00% <100.00%> (ø)
src/ClockService.ts	100.00% <100.00%> (ø)
src/OidcClient.ts	94.23% <100.00%> (ø)
src/OidcClientSettings.ts	98.33% <100.00%> (+0.08%)	:arrow_up:
src/RefreshState.ts	100.00% <100.00%> (ø)
... and 12 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 707435f...99ba5c8. Read the comment docs.

[pamapa]

@kherock I have problems with the unit-tests when i make the ClockService getEpochTime async. Any idea?

[pamapa]

I will drop the DateUtils and use instead ClockService as well. I would prefer a non promise callback solution, what do you think?

[kherock]

Is it a good idea to allow getEpochTime to be async? I would prefer that we maintain a way to cheaply obtain the current time. For example, the following seems reasonable to me

class ServerClockService extends ClockService {
  offset = 0;

  getEpochTime() {
    return super.getEpochTime() + offset;
  }

  async synchronize() {
    const serverTime = await fetchServerTime();
    this.offset = serverTime - super.getEpochTime();
  }
}

[pamapa]

Cosmetic: I was thinking at which position of the functions i should add the clockService parameter. I decided against putting it into args object (e.g. SigninRequest) as it should not be public and it does not change. Currently i have put it at the end of the function parameters, maybe its better to have it as first?

[pamapa]

I am going to split this MR, the first one reinstate the clock service, the second then goes beyond what oidc-client-js does. The first part should be simple and is already part of this MR. The second part will be trickery. Like this it will also be easier to review. And the first part could be seen as bugfix, where the second part is a feature...

[pamapa]

Other much simpler solution: Lets make Timer.getEpochTime changeable. I first thought because it is static, it is not such a good idea, but the use-case for this (#414) is to fix client time issues (embedded devices i guess). And not timezone issues between identity server and client.

@kherock Should i follow that way?