You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 6, 2018. It is now read-only.
Yes. Also, the IFileInfo API should expose dates as DateTimeOffset rather than as DateTime.
This will prevent consumers of IFileInfo from misinterpreting the data. It's too easy to look over DateTimeKind.
As a specific example, consider the aspnet/StaticFiles project, which consumes IFileInfo and has several cases where the RFC1123 format specifier ("r") is applied. The MSDN docs explain a common bug:
Although the RFC 1123 standard expresses a time as Coordinated Universal Time (UTC), the formatting operation does not modify the value of the DateTime object that is being formatted. Therefore, you must convert the DateTime value to UTC by calling the DateTime.ToUniversalTime method before you perform the formatting operation. In contrast, DateTimeOffset values perform this conversion automatically; there is no need to call the DateTimeOffset.ToUniversalTime method before the formatting operation.
One can't reliably expect consumers to remember this bit of trivia - therefore, it makes much more sense to expose a DateTimeOffset. Implementations like PhysicalFileSystem should populate the value from LastWriteTimeUtc, which when assigned to a DateTimeOffset, will cast implicitly and use a zero offset.
PR #25 addresses this. Note, it would not compile with LastWriteTimeUtc. I think it's missing from the core runtime, but not sure why. I used LastWriteTime.ToUniversalTime() instead. That should still work and produce the correct value.
https://github.com/aspnet/FileSystem/blob/dev/src/Microsoft.AspNet.FileSystems/PhysicalFileSystem.cs#L207-L210
LastWriteTimeUtc
The text was updated successfully, but these errors were encountered: