Scala是否有可用的日期/时间API？

Question

我正在寻找适用于Scala的类似于JodaTime或JSR 310的东西，它利用了Scala的很好特性，例如运算符重载，并且不依赖于隐式转换（我有一种不合理的对隐式转换的恐惧）。

我知道http://github.com/jorgeortiz85/scala-time, 但它只是通过隐式调用来装饰JodaTime。

- Erik Engbrecht

---

我建议你放下对隐式转换的不理性恐惧。;-) - Jesper

@Timo - 我想要比较操作，以及加号和减号之类的东西。@Jesper - 这种担忧并非完全没有道理。隐式转换会影响性能。它们可能会与相等性等事物产生奇怪的交互作用。它们依赖于类型推断，我发现混合许多依赖于类型推断的东西是绝对混乱的好配方。 - Erik Engbrecht

如果你想在Scala中使用JodaTime，并使用运算符重载进行比较等操作，你可以创建一个替代版本的JodaTime构建，例如将Ordered trait方法添加到AbstractPartial和AbstractInstant中。我知道这很冒险，但我也不喜欢隐式转换Pimp-my-library的用法。 - Timo Westkämper

@Erik Engbrecht - 你为什么说implicit有性能损耗？它们在编译时就已经解决了。在运行时，它们就像任何其他方法调用一样。 - sblundy

性能：Hotspot中的逃逸分析可以消除一些开销。但我还没有确切的数字。相等性：如果您在A上定义了一个带有转换到B的“新方法”，并且在新方法中返回B类型的内容（而不是A），它将仅混淆相等性。我认为，这就是RichString不对称的问题所在。 - Thomas Jung

Answer 1

没有隐式转换是错误的。即使底层逻辑没有使用Java库，任何设计合理的纯Scala库仍将使用隐式转换，允许您编写表达式，例如5.days + 3.minutes。

并非所有隐式转换都相同，对您具有完全控制的非常特定类型的隐式转换几乎肯定是安全的。

正如其他人已经指出的那样，在大多数情况下这样的转换将被优化掉，特别是在启用了逃逸分析的情况下，所以不要担心它们！

在JSR 310最终确定之前，joda-time是您能够获得的最佳选择。

除了需要遵循Java命名约定和缺少运算符重载之外，joda-time已经非常适合Scala成语。设计非常功能性，特别是它采用不可变性的方式，因此scalaj-time实际上只是一个对库进行了非常轻微的包装。

您还可以获得一个好处，即在可用时，scalaj-time可以轻松升级为使用JSR 310，因此在那个时候迁移您的代码将会更加轻松。

自2.8版以来，scala-time已更名为scalaj-time：http://github.com/scalaj/scalaj-time。

- Kevin Wright

---

我可以想象，从Scala的JodaTime包装器转换到Scala的JSR310包装器会比直接使用这些东西（或在Java中使用）要容易得多。如果只需更改导出和修复一些类名就足够了，那将是有趣的事情 :-) - soc

隐式转换在包装所做的事情之上添加了一个半隐藏的间接层。这增加了复杂性和运行时开销。作为一种特性，它们并没有什么问题，但有时会以不必要的方式使用它们。 - Erik Engbrecht

将一个裸整数转换为分钟数是不是有些多余？ - Kevin Wright