What’s in a name (again)?

I have possibly foolishly decided to stop resisting the urge to port Joda Time to .NET. For those of you who are unaware, "use Joda Time" is almost always the best answer to any question involving "how do I achieve X with java.util.Date/Calendar?" It’s a Java library for handling dates and times, and it rocks. There is a plan to include a somewhat redesigned version in some future edition of Java (JSR-310) but it’s uncertain whether this will ever happen.

Now, .NET only gained the ability to work with time zones other than UTC and the local time zone (using only managed code) – it has a bit of catching up to do. It’s generally easier to work with the .NET BCL than the Java built-in libraries, but it’s still not a brilliant position to be in. I think .NET deserves good date/time support, and as no-one else appears to be porting Joda Time, I’m going to do it. (A few people have already volunteered to help. I don’t know how easily we’ll be able to divvy up the work, but we’ll see. I suspect the core may need to be done first, and then people can jump in to implement different chronologies etc. As a side-effect, I may try to use this project as a sort of case in terms of porting, managing an open source project, and properly implementing a .NET library with useful versioning etc.)

The first two problems, however, are to do with naming. First, the project name. Contenders include:

  • Joda Time.NET (sounds like it would be an absolutely direct port; while I intend to port all the tricky bits directly, it’s going to be an idiomatic port with appropriate .NET bits. It’s also a bit of a mouthful.)
  • Noda Time (as suggested in the comments and in email)
  • TonyTime (after Tony the Pony)
  • CoffeeTime
  • TeaTime
  • A progression of BreakfastTime, CoffeeTime, LunchTime, TeaTime, DinnerTime and SupperTime for different versions (not a serious contender)
  • ParsleySageRosemaryAndThyme (not a serious contender)
  • A few other silly ones too

I suspect I’m going to go for CoffeeTime, but we’ll see.

The second problem is going to prove more awkward. I want to mostly copy the names given in Joda Time – aside from anything else, it’ll make it familiar to anyone who uses Joda Time in Java (such as me). Now one of the most commonly used classes in Joda is "DateTime". Using that name in my port would be a Bad Idea. Shadowing a name in the System namespace is likely to lead to very disgruntled users who may prove hard to regruntle before they abandon the library.

So what do I do? Go for the subtly different DateAndTime? Tie it to the library with CoffeeDateTime? Change it to Instant? (It’ll derive from AbstractInstant anyway – assuming I keep the same hierarchy instead of moving to a composition model and value types.)

Obviously this is a decision which the "team" can make, when we’ve got one… but it feels like a decision which is lurking round the corner in a hostile way.

What I find interesting is that these are two very different naming problems: one is trying to name something in a relatively arbitrary way – I know I want something reasonably short and memorable for the overall name, but beyond that it doesn’t matter too much. The other is trying to nail a very specific name which really has to convey its meaning clearly… but where the obvious name is already taken. Also interestingly, neither is a particularly good example of my most common issue with naming: attempting to come up with a two or three word noun for something that actually needs a whole sentence to describe it adequately.

Oh well – we’ll see what happens. In another blog post I’ll suggest some of the goals I have in terms of what I’m hoping to learn from the project, and how I’d like it to progress. In other words, expect a work of complete fiction…

If you’re interested in helping out with the project, please mail me directly (rather than adding comments here) and as soon as I’ve set the project up, I’ll invite you to the mailing list.

UPDATE: I’ve already got a few interested names, which is great. Rather than be dictatorial about this, I’ll put it to a vote of the people who are willing to help out on it.

53 thoughts on “What’s in a name (again)?”

  1. Not always the most beautiful thing in the world, but I’ve worked with several libraries that prefix their entities whose names are common or likely to collide with a letter or two – if it ends up being named CoffeeTime for example, we’d have CDateTime and CTimeSpan; or maybe CtDateTime and CtTimeSpan, etc.

  2. Actually – it should probably be Noda.

    As NUnit is to JUnit as Noda is to Joda.

    It also has the benefit of you then being able to say “Do you Noda time?”

  3. I like TonyTime. As to what to name DateTime… I dislike any sort of hungarian warts, like Rex M suggested. I had considered the problem before you posted this and I also came up with Instant. It describes what it is properly, and it fits in with the hierarchy: the default (i.e. most used) AbstractInstant is Instant.

  4. @Rex, and just a general comment:

    I definitely wouldn’t want to have to type prefixes in front of all of my types. I’ve worked in places that insist on prefixes and it drives me crazy.

    I can understand using CoffeeDateTime for the DateTime type, however. Just as long as the standard isn’t enforced consistently throughout the API.

  5. Damn, would like to work on that project too. But with my university studies, part-time work etc, I’m just too busy for now :(
    But I’ll follow it’s evolvement :)

    Regarding the name. What about: NetTime (for .Net and the word play Net = clean,easy,good). Just came to my mind right now.

    Greets,
    Juri

  6. Everytime I see this, I keep thinking Yoda Time…yeah, no direct relationship, but heck, Yoda was the master of the force and the universe, I’m sure he could whip some datetime/calendar objects into shape.

  7. I would strongly discourage any name except for DateTime. As a port, the types, especially the fundamental ones, should basically be called the same. Changing it would cause unnecessary confusion and frustration for those who work with both frameworks.

    Shadowing a type in the System namespace is not a concern as long as you put it in another namespace. How developers use (or not) using statements should not be your concern. Let them take responsibility for their choices.

  8. NJoda would be helpful in terms of lineage. As far as class names:

    TimeDate
    Chronometer/Chronometry
    WorkingDateTime

    …pretty tough when the BCL name is pretty good.

  9. “I don’t know how easily we’ll be able to divvy up the work, but we’ll see…”

    I’ve never looked at the JodaTime library but I’d imagine that it has plenty of atomic parts.

    If the Joda lib has unit tests then I’d dish those out to port and build a failing skeleton of a library to run them against first.

    Once you have a massive suite of failing unit tests in .Net I believe that dishing out work on filling-in-the-blanks will be much easier.

    If the Joda lib doesn’t have unit tests then I’d start off by having the team come up with as many use cases and the associated unit tests for those use cases.

    Good luck with the project!

  10. @Brian: I think it would be pretty grim if people couldn’t have “using System; using CoffeeTime;” or whatever and still access one of the main types in the library. I don’t want to force people to alias it all over the place. Yes, they have to take responsibility for their choices – but we should provide good choices to start with.

    As for unnecessary confusion and frustration – I’m sure there will be bits of code which need to work with both System.DateTime and the new type. Calling the new type DateTime as well seems to be the option which would cause the *most* unnecessary confusion and frustration.

    In particular, I have experience of *exactly* this pain: I regularly work with GData’s DateTime class in the same class where I’m using Joda Time’s DateTime class. It’s a *horrible* experience, and I don’t wish it on anyone else.

  11. @Guy: Fortunately, it does indeed have lots of unit tests. When I was discussing this at work, the “skeleton -> tests -> flesh” plan was exactly what we came up with. There’s quite an intricate type hierarchy in Joda, but it shouldn’t take *too* long to get that skeleton set up.

  12. Of the suggestions above, I like Noda for the name of the project best. I also would be fine with NodaTime as a replacement for DateTime – if NodaTime has a NodaTime.Date property, it will be pretty obvious it holds both a Date and Time – which a Date is a Time of a difference scale, and only because older databases/languages had separate Date and Time types do we keep these separate. (Generally, when someone wants only a Time, they really want a TimeSpan).

    I’m also for not making it a direct port – .Net BCL has a style (there is even a book on this style!), and unless there is good reason not to it makes sense to follow this style. I work with Lucene.Net often, and it always feels like I’m mixing oil and water since the .Net API and Lucene API have very different conventions.

  13. I’d agree with Michael C. Neel, both on using the name Noda and on calling the DateTime NodaTime.

    Gutted I don’t really have time to help on the project.

  14. I would strongly advise against naming the library “Coffee Time” or “Tea Time”, because if you google that name you’re going to get plenty of unrelated results… Also, CoffeeDateTime is too long and doesn’t look very serious for professional code ;)

    “Noda Time” seems the best option to me. As Iain has pointed out, it is the same pattern as JUnit/NUnit, and I think it sounds nice. You could call the class NodaDateTime (a bit long), or better : NDateTime.

  15. For the project: +1 to Noda (or Noda Time)
    For the type name: +1 to Instant or NodaTime over the others.

  16. my two cents
    Project Name: JodaTime.Net
    Datetime Name: JodaDateTime (since i imagine this object will be directly convertable to System.DateTime and would mimic the funtionality the name should be very similar. I imagine u would have a TimeSpan equivalent which could be JodaTimeSpan)

  17. @Zxpro, nice work. I was checking out WordNet for synonyms and I came up with exactly the same as you… Here’s what I think:
    Moment: similar to Instant, but with other connotations in different domains;
    PointInTime: kinda wordy, but probably the best at getting the meaning across.;
    TimePoint: shares the benefits of PointInTime, but it is not as natural. It has the advantage of being a two-word noun;

  18. Time.Net, or is that already taken?

    I must admit that YodaTime is quite cool :)

    I think I prefer PointInTime to Instant

    TimeDate too yucky?

  19. In your choice of the class names, also consider that `Date` is a keywords in VB. And as @rbirkby has commented, `DateAndTime` exists as a type name in the `Microsoft.VisualBasic` namespace which is imported *by default* in Visual Basic projects. So these two names, along with `DateTime`, are probably not good choices, unless you don’t care that the library won’t be usable from VB.

    Personally, I like the distinction `Instant` vs. `Period` best, the terms are succinct and technically accurate, and they form a nice pair of complementary concepts (better even than `DateTime` and `TimeSpan`, in my opinion).

    Someone commented about the searchability of terms like “TeaTime” or “CoffeeTime” – frankly, I wouldn’t be too worried. Any Open Source project hosting will guarantee a quite good search engine placement and once people start *using* the library and writing in blogs about it, the ranking will skyrocket. On the other hand, “Do you Noda time” is such a bad pun that I had to laugh.

  20. Googling for “Noda Time” brought up the fact that Noda is a city in Japan.

    On the other hand “Noda Time C#” already brings up this article first, so there shouldn’t be too much competition.

    I would recommend against “Coffee time” on that basis – since googling “Coffee time c#” doesn’t find this blog in the first two pages of results.

  21. @ Chris

    “Stop.” ;)

    I like YodaTime because it’s easy to say and amusing while clearly keeping the lineage with Joda. That said convention is J -> N so NodaTime is likely the most practical, and libraries should be practical.
    Anything with strong google noise should be avoided so sadly I think CoffeeTime should not be used.

    As to the naming of what was DateTime I like Instant for brevity while still being bang on the mark for what it is. Anyone copy/pasting Joda code to .Net will need to transform some bits anyway.

    Have you considered whether you are going to write Instant as a struct or not? It would be immutable so a fine candidate and would then behave much like the .net DateTime.

    Either way are you also going to provide an (implicit or explicit) conversion to/from System.DateTime?

  22. @ShuggyCoUk: It looks like Noda Time is the way we’re going at the moment – just waiting for more votes from the potential team.

    I don’t think I’ll be going for structs, for a few reasons:

    * In Joda there’s a relatively deep inheritance tree, which obviously doesn’t work with structs.

    * There are a lot of interfaces, and I’d prefer to avoid boxing for everyone who uses interfaces.

    * While the most commonly-used forms are immutable, there are *some* mutable types as well – and having a value type / reference type divide there could be painful.

    * I haven’t looked into how much state a Joda DateTime keeps – it may well only be a couple of fields, but it may be a bit heavier.

    I’m not sure about conversions to/from DateTime as implicit/explicit ones, but I’ll certainly have something like ToLocalDateTime, ToUtcDateTime and ToDateTimeOffset.

  23. Given that nUnit was a port of jUnit but making use of attitudes etc, I think you should use the same naming system. Most programmers will then know what nJodaTime is without having to be told. (Also anyone searching for “JodaTime .net” will match web pages about nJodaTime.)

    As to the naming of DateTime, it should:

    * Contain the work “Date” and or “Time” – so that .net programmer can read the code

    * Contain the work “Joda” – so that anyone reading the code asks “what is Joda”, rather then assuming it is a normal DateTime

  24. From the JodaTime FAQ:

    What is with the name ‘joda’?

    ‘Joda’ is a short, four letter name, beginning with ‘j’ whose domain name was free. It is not an acronym.

    Maybe checking domain names is also a good way to go?

  25. Can I ask what Joda Time does that the DateTimeOffset classes don’t do? DateTimeOffset fully supports TimeZone info and going to/from arbitrary timezones taking into account historical DST rules for the given source & destination. As it gets its information from the OS, it’ll also be updated as DST rules change.

  26. >* In Joda there’s a relatively deep inheritance tree, which obviously doesn’t work with structs.

    Yeah, that might be painful unless the inheritence tree was overkill and could be replaced with composition.

    > There are a lot of interfaces, and I’d prefer to avoid boxing for everyone who uses interfaces.

    The box would only occur when working with the interface. Would that really be the case for most people?

    > While the most commonly-used forms are immutable, there are *some* mutable types as well – and having a value type / reference type divide there could be painful.

    I was under the impression (Joda)DateTime was immutable but that it contained references to the Chronology which was, by default, immutable but could be mutable if you desired. This strikes me as fine for structness.

    * I haven’t looked into how much state a Joda DateTime keeps – it may well only be a couple of fields, but it may be a bit heavier.

    Yeah, if it’s very heavy that would be an issue.

    I’m not masssively for or against either. I just figure it’s a design decision that merits discussion at the beginning as it’s not something Joda had to even care about.

    Also given the interface aspect you may well be able to provide a struct and object nbased IInstant to let people pick and choose. Might make the library a nightmare though so really only food for thought.

  27. @onovotny: DateTimeOffset doesn’t include the time zone – just the offset. It doesn’t let you predict what the time will be in five minutes, for example, because you don’t know whether DST is about to kick in.

    Also, Joda Time has a much richer set of concepts – local date, local time, local date time, instant, period, duration etc which are all represented with their own types. This makes them easier to work with.

  28. @Shuggy: My point about mutability is that there’s a MutableDateTime as well – having a MutableInstant class but an Instant struct would be a bit odd.

  29. @jon: “predict what the time will be in five minutes” lol

    That would have been a great example line for you Epic Fail talk: “We can’t even predict what the time will be in five minutes!”
    Btw, the answer is “five minutes later”.

  30. Plus one vote for Noda Time for me.
    And if the name for this project will not be CoffeeTime there should still be a framework with that name.

    CoffeeTime.IsItCoffeeTime();

  31. I’m going to go a bit controversial here.

    For the base datetime type, I’d suggest DaTime. It conveys, phonetically, the two types being married, and would also fit, to some extent, if we go for Noda Time

  32. on domain names:

    nodatime.com is already taken.
    nodatime.net does seem available.

    Domain Name: NODATIME.COM
    Registrar: MELBOURNE IT, LTD. D/B/A INTERNET NAMES WORLDWIDE
    Whois Server: whois.melbourneit.com
    Referral URL: http://www.melbourneit.com
    Name Server: YNS1.YAHOO.COM
    Name Server: YNS2.YAHOO.COM
    Status: clientTransferProhibited
    Updated Date: 31-jan-2009
    Creation Date: 11-feb-2006
    Expiration Date: 11-feb-2010

  33. Noda Time is fine; as the Joda Time FAQ says, all you really need is something memorable that isn’t already taken.

    I think I like Instant, but given how important this name will be to the library as a whole, I think it deserves a lot more thought and discussion.

Comments are closed.