{"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":74,"created_at":"2015-06-21T06:18:34Z","updated_at":"2015-06-26T05:08:20Z","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/115515135","html_url":"https://github.com/dotnet/corefx/issues/2116#issuecomment-115515135","issue_url":"https://api.github.com/repos/dotnet/corefx/issues/2116","id":115515135,"user":{"login":"ronnyek","id":584713,"avatar_url":"https://avatars.githubusercontent.com/u/584713?v=3","gravatar_id":"","url":"https://api.github.com/users/ronnyek","html_url":"https://github.com/ronnyek","followers_url":"https://api.github.com/users/ronnyek/followers","following_url":"https://api.github.com/users/ronnyek/following{/other_user}","gists_url":"https://api.github.com/users/ronnyek/gists{/gist_id}","starred_url":"https://api.github.com/users/ronnyek/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ronnyek/subscriptions","organizations_url":"https://api.github.com/users/ronnyek/orgs","repos_url":"https://api.github.com/users/ronnyek/repos","events_url":"https://api.github.com/users/ronnyek/events{/privacy}","received_events_url":"https://api.github.com/users/ronnyek/received_events","type":"User","site_admin":false},"created_at":"2015-06-26T05:08:20Z","updated_at":"2015-06-26T05:08:20Z","body":"These threads are starting to feel a bit like the the discussions about net neutrality or patriot act... nobody wants the change, but we gotta just keep trying to RAM in on through, change verbiage, come up with new arguments for it, and hope this time the same people don't pop up fighting it. I have to say I've seen the arguments for this sort of thing by maybe one or two people, and those two people are just incredibly incredibly vocal about it.\r\n\r\nMy personal opinion is that I think it'd be a huge mistake.  "}}