Reconcile ISystemClock with the one from Security

[Tratcher]

Both MemoryCache and Security define ISystemClock. Can/Should these be consolidated?

We'll need to resolve DT vs DTO first. See aspnet/Caching#6

[ycrumeyrolle]

Any chance to see it as a shared component?
I have build some middleware that have a dependency on it.
When there is a dependency on both MemoryCache & Security, which one should be used ?

And you may need to define a third one with ResponseCaching.

[Tratcher]

The feature is designed exclusively for unit testing so there has been little motivation to consolidate them. Especially after ANIs got cut so now it would have to live in a shared dependency somewhere.

What kind of middleware are you using it in?

[ycrumeyrolle]

I have 3 middlewares using it ;

• a performance counter middleware. The ISystemClock is used to measure the time taken,
• a throttling middlware. The ISystemClock is mainly used to manage the Retry-After response header,
• a proxy cache middleware, which should be quite the same than the new ResponseCache. The ISystemClock is used to manage the content expiration.

As a component developer, I can manage to live with two or more ISystemClock. I may have to create an using alias directive - I don't like alias - but its OK.
In addition, dates are not a very common type, especialy the current date.

As an application developer, I will have more difficulties. DateTime.Now & Co. are more frequently used.
I will have to explain to my team :

If you have a dependency on Caching, you can use the ISystemClock in namespace Microsoft.Framework.Internal.
If you have a dependency on Security, you can use the ISystemClock interface in namespace Microsoft.AspNet.Authentication.
If you do not have a dependency on one of them, you have to create your own ISystemClock.
If you use both of them, you should use the ISystemClock from :
[ ] Microsoft.Framework.Internal.
[ ] Microsoft.AspNet.Authentication.
[ ] Your own namespace.
[ ] DateTime.Now <== Default choice

Too many possibilities, too many choices. And it is not DRY/DRO (Don't Repeat Others !)

My point of view is that ISystemClock is very useful, even outside of aspnet.
As ANI is dead (is there any explanation of it?), it cannot be placed as a common source package.
Is it too small for a specific package, like Microsoft.Framework.Clock/Common/Core/Abstractions/... ?

[Eilon]

@KrzysztofCwalina any thoughts on having an ISystemClock in the BCL?

[KrzysztofCwalina]

I am torn. I do think it would be better to have common abstractions in the BCL and I definitely think it's better to have one such abstraction than two. But I also feel like many of these abstractions add complexity to frameworks that is often not offset by the benefits, especially when they are bolted-on existing APIs that were not designed for DI from grounds up.
If we were to design and ship a new "dates and times" components, I can see how such abstraction would be part of it, but simply adding ISystemClock to the System namespace does not feel right.
We have started to talk about such new date and time package, but I am not sure how far the conversations/prototypes went, @mj1856, are you still planning to work on new dates and times package?

Also, I would make it an abstract class, not an interface. :-)

[mattjohnsonpint]

The "mock-the-clock" pattern is a very good one, and there are lots of implementations of this. For example, Noda Time has an IClock interface, with SystemClock and FakeClock implementations, plus my NetworkClock extension. I've also seen alternative implementations, such as the SystemTime class in RavenDB.

Yes, I am almost complete with the new date and time package. However, it is primarily focused on adding two new core data types, System.Date and System.TimeOfDay. There are a few extension methods in there as well, but I'm not sure if ISystemClock would be a good addition or not.

It would be something easily added, sure. But it doesn't solve any specific problem that couldn't easily be done outside the BCL, such as the two ISystemClock implementations you have today. Wouldn't it be just as easy to move them to some core aspnet dependency?

I guess it comes down to whether or not we feel there should be a single abstractable clock mechanism to use throughout the framework or not. I'm happy to have them there, just torn on whether it's the right move.

@tarekgh might have an opinion on this as well.

[mattjohnsonpint]

@ycrumeyrolle - Your first use case, "to measure the time taken" you should rely on System.Diagnostics.Stopwatch. The system clock (abstracted or not) is not a reliable source for measuring the elapsed time of an operation because:

1. The precision of DateTime.UtcNow is that of the RTC, which is around 10ms or so on modern hardware. Stopwatch uses QPC, which offers a much higher precision. See Acquiring high-resolution time stamps on MSDN.
2. The system clock will drift, due to the nature of the crystal oscillator the RTC uses, and the OS will correct for drift periodically.
3. The system clock can be adjusted by NTP sync, or fiddled with by the user without any regard to current operations being timed.

Also, you mentioned DateTime.Now, which has all of the above problems, plus the potential for errors during daylight saving time transitions. See The case against DateTime.Now.

[ycrumeyrolle]

@mj1856 I am agree with you, the system clock may not be the most efficient way to measure elapsed time. But in my use case 10ms precision is fair enough, for now...