Skip to content
This repository was archived by the owner on Nov 6, 2018. It is now read-only.

IFIleSystem should use UTC dates \ regular #9

Closed
pranavkm opened this issue Jul 11, 2014 · 3 comments
Closed

IFIleSystem should use UTC dates \ regular #9

pranavkm opened this issue Jul 11, 2014 · 3 comments

Comments

@pranavkm
Copy link
Contributor

https://github.com/aspnet/FileSystem/blob/dev/src/Microsoft.AspNet.FileSystems/PhysicalFileSystem.cs#L207-L210

LastWriteTimeUtc

@mattjohnsonpint
Copy link
Contributor

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.

@mattjohnsonpint
Copy link
Contributor

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.

@Praburaj
Copy link
Contributor

I think this can be closed as the PR is merged.

@Tratcher Tratcher added this to the 1.0.0-rc1 milestone Dec 29, 2014
@Tratcher Tratcher assigned pranavkm and unassigned pranavkm Dec 29, 2014
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants