Add properties Now and Today

[EdwinEngelen]

Newly added module DateAndTime with read-only properties Now and Today. Implementation is the same as in netfx.

Property Today is writable in netfx and uses kernel32.dll. That's not possible in corefx, thus property is read-only.

I tried to add tests, but experienced two problems:

• Faking DateTime.Now requires the use of ShimsContext. Then it's no longer safe to run tests in parallel, which is what probably happens.
• I couldn't find out how to add the fakes assembly, because I couldn't see the netstandard assembly in the reference list.

[stephentoub]

That's not possible in corefx

Why? At least on Windows that should be doable. I expect there's an equivalent that could be done on other platforms, like using settimeofday, but if there really isn't any way it could be implemented on unix it should still be added but then throw PlatformNotSupportedException.

[stephentoub]

I tried to add tests

You should still be able to test it, e.g.

• Call DateTime.Now and store the result
• Call DateAndTime.Now and store the result
• Call DateTime.Now and store the result
• Validate that the middle result was >= to the first and <= to the second. You can convert these to UTC to do the comparisons.

[EdwinEngelen]

• I've added tests. Are these as proposed?
• Set date/time: Do we need to implement these now? I think it's okay to add that later. I also don't know how to implement it for other platforms. Throwing PlaformNotSupportedExcepton might not be a good idea, because that results in runtime errors and not in compilation errors.

[stephentoub]

Do we need to implement these now? I think it's okay to add that later.

If we're adding the properties now, I think we should add them correctly now.

[EdwinEngelen]

I think we should add them correctly now

Then I'll need some help from someone.

[karelz]

@OmarTawfik can you please help move the PR forward?

[danmoseley]

@EdwinEngelen could you rebase?

@stephentoub I think it is reasonable to check in just the getters alone as a step along for https://github.com/dotnet/corefx/issues/31181. It is not possible for us to forget the setters as they don't show in the ref, and there is presumably code that only use the getters.

[stephentoub]

It is not possible for us to forget the setters as they don't show in the ref

Does that mean we have tooling that shows up everything we're supposed to have but are missing, it's currently showing the getters and setters, and once this goes in it'll still show the setters?

[OmarTawfik]

@danmosemsft can you please elaborate on It is not possible for us to forget the setters as they don't show in the ref? what guards do we have in place to make sure the new APIs we add actually match the old ones (other than manual review)?

[OmarTawfik]

today [](start = 27, length = 5)

maybe also assert that time component is set to zeroes?

[EdwinEngelen]

Yes, we need that assertion too. Thanks!
I rebased and tried to add the assertion, but somehow VS gives me strange compile errors. System.Object not defined, …
I'm on holiday and don't have time to figure it out right now.

[danmoseley]

Does that mean we have tooling that shows up everything we're supposed to have but are missing, it's currently showing the getters and setters, and once this goes in it'll still show the setters?

Yes, if you count running genapis and windiff, or Apireviewer, when we believe we are done or ready to review where we are at. Something which we would do for any library port, but especially in this case where there was a very selective existing surface area.

what guards do we have in place to make sure the new APIs we add actually match the old ones (other than manual review)?

The build validates our implementation (src) against our contract (ref) in both directions, but there is no automatic verification against .NET Framework surface area. That is what is done by diffing the output of genapis on the binaries.

[danmoseley]

Thanks @EdwinEngelen