{"action":"created","issue":{"url":"https://api.github.com/repos/dotnet/corefx/issues/2116","labels_url":"https://api.github.com/repos/dotnet/corefx/issues/2116/labels{/name}","comments_url":"https://api.github.com/repos/dotnet/corefx/issues/2116/comments","events_url":"https://api.github.com/repos/dotnet/corefx/issues/2116/events","html_url":"https://github.com/dotnet/corefx/issues/2116","id":89870895,"number":2116,"title":"API proposal/RFC - System.Time namespace","user":{"login":"Clockwork-Muse","id":5569508,"avatar_url":"https://avatars.githubusercontent.com/u/5569508?v=3","gravatar_id":"","url":"https://api.github.com/users/Clockwork-Muse","html_url":"https://github.com/Clockwork-Muse","followers_url":"https://api.github.com/users/Clockwork-Muse/followers","following_url":"https://api.github.com/users/Clockwork-Muse/following{/other_user}","gists_url":"https://api.github.com/users/Clockwork-Muse/gists{/gist_id}","starred_url":"https://api.github.com/users/Clockwork-Muse/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Clockwork-Muse/subscriptions","organizations_url":"https://api.github.com/users/Clockwork-Muse/orgs","repos_url":"https://api.github.com/users/Clockwork-Muse/repos","events_url":"https://api.github.com/users/Clockwork-Muse/events{/privacy}","received_events_url":"https://api.github.com/users/Clockwork-Muse/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":90,"created_at":"2015-06-21T06:18:34Z","updated_at":"2015-06-27T13:15:01Z","closed_at":null,"body":"(aka [\"programmers for good dates\"](https://gitter.im/dotnet/corefx/archives/2015/06/19))\r\n\r\nRelated: \r\n#700 - Adding `Date` and `Time` types.\r\n#626 - Deprecating `DateTime.Now`.\r\n\r\nSee also:\r\n[What's wrong with `DateTime` anyway?](http://blog.nodatime.org/2011/08/what-wrong-with-datetime-anyway.html)\r\n\r\nDate and Time are foundational concepts in our daily lives, and in programming; it's why we have `DateTime`.  \r\nUnfortunately, `DateTime` isn't sufficient.  Date and time are part of a larger ecosystem of concepts, ranging from an absolute point in time something occurred (an `Instant`), to the value reported on a wristwatch (`LocalTime`).  They're related, and you can (usually) transition or convert from one to the other, but they are very definitely not the same thing.\r\n\r\nBut wait!  We have [NodaTime](https://github.com/nodatime/nodatime)!  Well, the biggest problem with NodaTime is... it's a separate, third-party library.  It means we can't take dependencies on it.  This results in things like [OData having a separate `Date` type for XML compliance](https://github.com/OData/odata.net/blob/master/src/Microsoft.OData.Edm/Library/Date.cs) (and there are other examples in different namespaces).  There's a lot of stuff that NodaTime does, and does well, and most of it is stuff that the default libraries should be handling (like, say, time zone ids from non-windows sources).\r\n\r\nWhat about patching some common holes with new, standard types (ie, Matt's [`Date` and `Time` types](https://github.com/mj1856/corefx-dateandtime))?  This alleviates some problems for us, but leaves the problem when _interacting with NodaTime_.  That is, \"Why do I have to use the deficient framework types/something else to do XML serialization!?\".  (Note NodaTime has been looking to get the library installable on SQLCLR; I don't think it's made it into a release yet).  Oh, and it means we have to keep three time zone databases in sync, instead of two (at least on windows).\r\n\r\n<hr />\r\nSo: I'm proposing a new namespace as a modern, good implementation of a date and time library, our own version of JSR310/java.time .  We need a good set of narrow value types, and a range of support classes to handle conversions and many other use cases.\r\n\r\nUnfortunately... I... don't have an API on hand: I'm creating this issue to get things started.  Coming from the Java world, I really like the new java.time library, but don't know if we can (or should, really) do a straight port.  It's possible we might just use NodaTime; however that library was deliberately implemented with limited extensibility, something we would need to consider (ie, no custom calendars).  It would be good to ask Jon Skeet what version 8.0 would look like, if we went that route.\r\n\r\n<hr />\r\nKnown pain points:\r\n\r\n - VB aliases `DateTime` to `Date`.  This limits type names somewhat.\r\n\r\n<hr />\r\nEnd-of-life considerations:\r\n\r\nFirst, even if we had an implementation _now_, corefx isn't releaseable yet.  Then, there's whatever delay is involved in possibly getting such a library into the desktop release, and into wider distribution.  So nothing is going anywhere any time soon.\r\n\r\n - NodaTime: The aim (regardless of whether we include it or write a new one) is to supersede the standalone library.  We should be covering most, if not all, of its current use-cases.\r\n - `DateTime` (and other existing types): eventually, mark obsolete/deprecate (and remove?).  Timeline for this is probably multiple versions **after** release, although documentation should be changed to point to the new types as part of the initial one.\r\n - VB aliasing: Tricky.  The current usage implies the wrong type (that is, it's not just a calendar date).  It's possible the aliasing should be removed altogether, if the old types are removed.  Leaving it behind would be a major confusion point.\r\n\r\n<hr />\r\nInterested parties (?):\r\n@jasonwilliams200OK , @mj1856 , @gafter , @paulirwin , @tarekgh, @eatdrinksleepcode , @michaelstaib , @HaloFour , @ellismg \r\n\r\n@jskeet (Jon Skeet - NodaTime lead)\r\n@jodastephen (Stephen Colebourne - JodaTime and java.time implementer - informational/possible wisdom only)"},"comment":{"url":"https://api.github.com/repos/dotnet/corefx/issues/comments/116045634","html_url":"https://github.com/dotnet/corefx/issues/2116#issuecomment-116045634","issue_url":"https://api.github.com/repos/dotnet/corefx/issues/2116","id":116045634,"user":{"login":"Clockwork-Muse","id":5569508,"avatar_url":"https://avatars.githubusercontent.com/u/5569508?v=3","gravatar_id":"","url":"https://api.github.com/users/Clockwork-Muse","html_url":"https://github.com/Clockwork-Muse","followers_url":"https://api.github.com/users/Clockwork-Muse/followers","following_url":"https://api.github.com/users/Clockwork-Muse/following{/other_user}","gists_url":"https://api.github.com/users/Clockwork-Muse/gists{/gist_id}","starred_url":"https://api.github.com/users/Clockwork-Muse/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Clockwork-Muse/subscriptions","organizations_url":"https://api.github.com/users/Clockwork-Muse/orgs","repos_url":"https://api.github.com/users/Clockwork-Muse/repos","events_url":"https://api.github.com/users/Clockwork-Muse/events{/privacy}","received_events_url":"https://api.github.com/users/Clockwork-Muse/received_events","type":"User","site_admin":false},"created_at":"2015-06-27T13:15:01Z","updated_at":"2015-06-27T13:15:01Z","body":"@tarekgh - ... NodaTime _has_ pretty much everything we want already.  I only have one quibble with the library regarding an extension point (probably a required change if we included it in core).  It's not an issue with getting 3rd parties to take the dependency, I was more wanting **corefx** to be able to take the dependency, to help interop with other 3rd parties (by returning NodaTime types throughout core, instead of forcing conversions to/from to operate on core).  I'd only really want a new library if there were too many issues attempting to integrate NodaTime.\r\nI agree we can't break current Desktop apps, but I think it's mostly a non-issue; they default to run against the version they were compiled against, and only grab the latest version if they can't find the original version on the host machine.  I'm not sure of the granularity this resolves to, but in theory since all currently supported versions of Windows ships with 4.x, simply waiting to ship until 5.x would allow us to deprecate/remove DateTime safely (although I don't know if I'd remove the type immediately, it would be preferable to remove its use from core libraries in favor of the new types).  Would the code still break for developers?  Yes, but they should be free to target the old framework if necessary.\r\nIf somebody knows more about how this sort of resolution works on the desktop, please correct me if I'm wrong, or there's something I haven't considered.\r\n\r\n@jakesays - the problem isn't DateTime's sufficiency (java.util.Date was sufficient, come to that), it's that we're putting the cognitive load on the developer, instead of offloading to types.  Even attempting to do simple stuff runs risks because of DateTimeKind - for instance, if I'm attempting to write a simple calendar app, I have to remember to coerce all incoming dates to Unspecified, and zero out the time portion just so I can safely compare the 'Date' portion.  Calling DateTime.Date alone isn't necessarily safe, because it returns the value \"at midnight\"... which doesn't exist for all dates in all timezones (or exists twice.  I hate DST).\r\nIf you're careful with your code, you can deal with local-vs-Utc without too much trouble, but wanting some 3rd time zone means **you** have to manage it (this time zone belongs to this date...).  You have to make sure you convert before doing comparisons with local/utc dates, or your results are off.  None of this is intuitive, and some of the dangers are non-obvious to new programmers - if they notice them at all.  Like trying to get the number of days between two dates via `(int) TimeSpan.TotalDays`, which _usually_ returns the correct results, but will occasionally give wrong results if you're in Local (much less if the other date is a different DateTimeKind).\r\nI'm with @jskeet - a lot of current code is broken, or perilously close to it.  If your code is safe, you're doing a lot of work you shouldn't really have to."}}