Is there a good date/time API available for Scala? [closed]

Question

I'm looking for something akin to JodaTime or JSR 310 for Scala that leverages nice Scala features such as operator overloading and doesn't rely on implicit conversions (I have an irrational fear of implicit conversions).

I'm aware of http://github.com/jorgeortiz85/scala-time, but it just pimps JodaTime with implicits.

Workout

Are you looking for something which provides <, > operators? – Causeway

I suggest you get rid of your irrational fear of implicit conversions. ;-) – Tabby

@Timo - I'd like the comparison operations, along with things like + and minus. @Tabby - The fear isn't entirely irrational. Implicits have a performance hit. They can induce weird interactions with things like equality. They rely on type inference, and I've found mixing lots of things that rely on type inference is a good recipe for absolute confusion. – Workout

If you want to use JodaTime with Scala using operator overloading for comparison etc you could make an alternative build of JodaTime, for example adding the Ordered trait methods to AbstractPartial and AbstractInstant. I know this is risky, but I also dislike the implicit conversion Pimp-my-library usage. – Causeway

@Erik Engbrecht - why do you say that implicits have a performance hit? They're resolved at compile time. At runtime they're just like any other method call. – Certify

@Certify unless something changed recently, the implicit conversions used to pimp a class work by instantiating a wrapper object and then invoking the method on the wrapper. I know there's been talk about optimizing this away because this pattern is used so heavily, but to my knowledge it hasn't been done. – Workout

Performance: Escape analysis in hotspot can remove some overhead here. But I have no hard numbers, yet. Equality: If you define an "new method" on A with a conversion to B it will only confuse equality if you return something of type B in the new method (not A again). I think, this was the problem with RichString not being symmetric. – Syllabic

@Thomas Jung I think Escape Analysis is disabled in current JVM releases. I also haven't had much luck with more advanced HotSpot optimizations actually taking place. They tend to require the stars to align just right, so you end up spending a lot of time doing JVM tuning. That being said I'm far more concerned with avoiding unneeded contortions of the type system. Library pimping can be really convenient but in general I think it's a hack (although much better than monkey patching). I think plain wrappers are strongly preferable. – Workout

Answer 1

There's nothing wrong with implicit conversions. Even if a Java library wasn't used for the underlying logic, any sensibly designed pure Scala library would still use implicits, allowing you to write expressions such as 5.days + 3.minutes.

Not all implicits are created equal either, an implicit converting to a very specific type that you have full control over is almost certainly safe .

As others have already stated, such conversions will be optimised away in most cases, especially with escape analysis turned on, so don't let them worry you!

Until JSR 310 is finalised, joda-time is the best you're going to get.

Other than the need to follow Java naming conventions and a lack of operator overloading, joda-time is already a very good fit for idiomatic Scala. The design is very functional in nature, especially the way it embraces immutablity, so scalaj-time is actually only a very thin wrapper around the library.

You also get the benefit that scalaj-time can be easily upgraded to use JSR 310 when it's available, so it'll be much less painful to migrate your code at that time.

Since 2.8, scala-time has been renamed scalaj-time: http://github.com/scalaj/scalaj-time

Madge

I can imagine that moving from Scala's JodaTime wrapper to Scala's JSR310 wrapper will be much less pain than using those things directly (or in Java). Would be fun if changing the export and fixing some class names would be enough :-) – Sedimentation

Implicit conversions add a semi-hidden layer of indirection above what wrapping does. This adds both complexity and runtime overhead. There is nothing wrong with them as a feature, but occasionally they are used in gratuitous ways. – Workout

Is it gratuitous to convert a naked integer to a number of minutes? – Madge