{"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":34,"created_at":"2015-06-21T06:18:34Z","updated_at":"2015-06-24T21:47:09Z","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/115021209","html_url":"https://github.com/dotnet/corefx/issues/2116#issuecomment-115021209","issue_url":"https://api.github.com/repos/dotnet/corefx/issues/2116","id":115021209,"user":{"login":"mj1856","id":1396388,"avatar_url":"https://avatars.githubusercontent.com/u/1396388?v=3","gravatar_id":"","url":"https://api.github.com/users/mj1856","html_url":"https://github.com/mj1856","followers_url":"https://api.github.com/users/mj1856/followers","following_url":"https://api.github.com/users/mj1856/following{/other_user}","gists_url":"https://api.github.com/users/mj1856/gists{/gist_id}","starred_url":"https://api.github.com/users/mj1856/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mj1856/subscriptions","organizations_url":"https://api.github.com/users/mj1856/orgs","repos_url":"https://api.github.com/users/mj1856/repos","events_url":"https://api.github.com/users/mj1856/events{/privacy}","received_events_url":"https://api.github.com/users/mj1856/received_events","type":"User","site_admin":false},"created_at":"2015-06-24T21:47:08Z","updated_at":"2015-06-24T21:47:08Z","body":"Just want to say that I love the feedback so far - soapboxes and all!  Keep it coming!\r\n\r\nWRT leap seconds, I'll dump some info here.\r\n\r\nI agree with leaving them out of .NET, for several reasons.\r\n 1. Leap seconds are part of the domain of clock synchronization.   They're important for operating systems and NTP servers, not application frameworks.\r\n 2. Windows doesn't do anything with leap seconds outside of w32tm, of which it generally ignores them.  It would be difficult to support leap seconds in the framework if they're not supported in the underlying OS.  (I'm not sure 100% about other OS's handling, but I don't think it matters much anyway.)\r\n 3. It's extremely rare to need to parse a leap second.  They *are* allowed by ISO-8601, but in practice, I've never encountered a parser implementation that supports them.\r\n 4. Application contexts that *need* leap seconds are mostly limited to the already specialized domains of astronomy, astrology, and global positioning (GPS clocks need a leap-second table to get an accurate UTC time).   Other than those, there's not a whole lot of actual purpose for them (IMHO).\r\n 5. Most applications have to contend with the fact that computer clocks are imprecise instruments *anyway*.  They can be fiddle with by the user, they drift, and they are \"corrected\" via NTP sync and other OS-level processes.  Applications that need \"perfect\" timing would have to consider using [specialized hardware](https://www.meinbergglobal.com/english/products/pc-clocks.htm) anyway.\r\n\r\nFor more about leap seconds on Windows, and why this will be a non-event, see [M3's blog post on MSDN](http://blogs.msdn.com/b/mthree/archive/2015/06/01/2015-leap-second-060115.aspx).\r\n\r\n"}}