Jon Skeet, a software engineer at Google and Microsoft C# MVP, has announced version 1.0 of Noda Time, a .NET port of the popular Joda Time date/time library for Java.
Noda Time is intended to fix flaws in the .NET data/time libraries and to reduce complexity in using them. Noda Time uses a number of key concepts: Instant – a moment measured from the Unix epoch, Partial – a partial data/time representation, Interval – an interval of time from one ms instant to another, Duration – the duration of a time interval measured in ms, Period – a period of time expressed in fields (e.g. 5 months 3 days 6 hours), Chronology – a pluggable calendar system, Time Zones updated based on the tz database.
Although the porting of Joda Time to .NET took 3 years and there is still more work to do, Skeet is happy with the results, considering that “we're already significantly ahead of most other date/time APIs I've seen in terms of providing a clean API which reduces *incidental* complexity while highlighting the *inherent* complexity of the domain.”
InfoQ has contacted Skeet to find out more about Noda Time and his plans for the future.
InfoQ: What features does Noda Time 1.0 offer and .NET 4.5 does not?
JS: Basically, the types in the BCL are very limited - we've basically got two types (DateTime and DateTimeOffset) to represent a whole range of possible concepts you might want to represent. Noda Time has a wider range of types, which can help keep the developer focused on the kind of data they're really working with. It's a deliberately restrictive API, which attempts to stop you from performing operations which really don't make sense.
For more on what I dislike about the BCL types, see my blog post about DateTime.
Fundamentally, I think APIs ought to expose functionality with four goals in mind:
- Force the user to take certain decisions (rather than trying to hide important aspects of the domain from them)
- When they've made those decisions, allow them to express those decisions in clear code - and do all the work behind the scenes to act on those decisions
- As far as possible, only allow meaningful operations to be expressed
- Encourage code to be written in a testable way
On top of providing a generally saner API for dates and times, Noda Time provides an implementation of the TZDB/zoneinfo/Olson/IANA time zone information.
InfoQ: What plans do you have for its future?
JS: That will partly depend on our users, of course. There are definitely some incomplete areas - we want more text handling (parsing ZonedDateTime and OffsetDateTime, for a start), and PCL support. Serialization in various guises looms large too - we have some Json.NET support already in an experimental form (separate from the main assembly), and I expect we'll add XML and binary serialization when we're convinced we got the main concepts right in v1.0.
InfoQ: Does Noda Time work with any .NET version? How about Mono?
JS: Currently we target .NET 3.5+, but only on the desktop. We want to support Portable Class Libraries (PCL) but that will require quite a bit of work, mostly cutting out features which require framework support which is unavailable in the PCL.
The code is designed to work with Mono, and we test on Mono as far as we can, but we've run into various issues in the stable released versions of Mono, mostly around cultures and TimeZoneInfo. Hopefully Mono 3.0 addresses at least some of these problems. For the plain computational side of things, and when using TZDB, Mono works fine. Obviously this will always be a bit of a moving target - we're going to put more effort into documenting exactly what problems we've seen on what OS/version combinations.
