Create a more robust date/time crate

[brson]

Just clone JodaTime. Start out of tree.

[emberian]

https://github.com/mozilla/rust/wiki/Lib-datetime and https://mail.mozilla.org/pipermail/rust-dev/2013-September/005528.html provide a detailed analysis of what a proper datetime library should look like. http://blog.joda.org/2009/11/why-jsr-310-isn-joda-time_4941.html?m=1 explains shortcomings of jodatime.

[emberian]

cc @luisbg

[luisbg]

@cmr do you want help with this?

[emberian]

@luisbg I think I'll be able to, yes.

[netvl]

Maybe cloning JSR-310 which is implemented in Java 8 is more approriate? It is made by the same people learning on mistakes made when creating Joda-Time, as they stated themselves (the link provided by @cmr).

[kud1ing]

See also https://github.com/lifthrasiir/rust-chrono
Ping @lifthrasiir

[jimmoores]

I'd seriously recommend basing it on JSR-310 rather than JodaTime. Note that there are some extras that 310 had that got stripped out of Java 8. See http://threeten.org.

[kud1ing]

On Hackernews the concern was raised that duplicating APIs might give trouble: http://www.reuters.com/article/2014/05/09/us-oracle-google-ruling-idUSBREA480KQ20140509

[luisbg]

After me research and the opinion of other people who joined the discussion, we agreed that JSR-310 was a better basis to work from.

I don't think a similar API is a problem when JSR-310 is under the BSD license.

[joewalker]

@jodastephen is:

A. The author of JodaTime
B. A super nice guy
C. Something of a programming language nerd, so he would probably be interested in knowing that people were thinking of porting 310 to Rust.

(And I think that @ ing someone lets them know?)

[emberian]

(yup, @-mention will send them a notification)

It'd be very nice to have a domain expert lending a hand, even if it's just for guidance!

[jodastephen]

I'm happy to answer questions on JSR-310. The key is the separations it has between local date/time, zoned date/time and instants. Those distinct types allow developers to model their domains accurately and effectively. Other parts of JSR-310 (the chrono and temporal package) could be adopted as is, but there may be a better way in a different programming language.

If you want to avoid license issues, look at the source code for ThreeTen/threetenbp which is the BSD fork from code pre-OpenJDK..

[brson]

Thanks, @jodastephen. On the subject of licensing I did want to mention that everybody involved needs to avoid doing direct ports of copyleft code to Rust. Implement API's; don't copy code. Use the BSD repo @jodastephen mentioned and not the (presumably GPL) OpenJDK code for reference.

I have no idea how the new precedents about API copyright might apply in cross-language situations, but I'm guessing a Rust API is going to necessarily look somewhat different from a Java one.

[ogham]

I've been doing some thinking about this, and I've been writing code at such a slow pace that I don't have it in a repository just yet, but there are a number of ways that Rust language features would make the API differ from a Java implementation:

• Date and time formatters could be built using a macro, and have their syntax checked at compile time, similar to the format or regex macros. Then they can be used to parse and format dates without having to worry about invalid formatting. (Coincidentally, I had a bug only yesterday at work that was caused by me using y instead of Y in the string and assuming it was correct... bad move)
• Durations and Periods could be moved into the same enum, with both constructors for an exact number of milliseconds and ones for periods such as Days or Months. We wouldn't need methods such as addHours or addMinutes when we could instead provide an Add implementation on Instant and Duration, and could write something like Time::now() + Hours(3).
  (I'm not sure about 3.hours(), but it's certainly possible.)
• A Chronology looks like it could be a typeclass, with to_instant and from_instant methods that convert between Instants and a number of milliseconds since an epoch. These values could then be converted to LocalDateTime structs in much the same way as Joda.

I'm currently waiting on a date/time crate for my personal project, which was why I started thinking about this, so I'd be happy to contribute to whatever comes up.

[luisbg]

I only got started with this but it might be worth mentioning:
https://github.com/luisbg/rust-datetime

[brson]

FYI, #11189 needs a ns-precision duration type for I/O timers. If such a data type already exists in one of these libraries we might want to consider how to integrate just that piece.

[kaisellgren]

I suppose this has nothing to do with this lib: https://github.com/depp/datetime-rs

[John-Nagle]

So whatever happened with providing some usable date/time functions?
"https://github.com/depp/datetime-rs" isn't packaged as a Cargo crate, so it's not importable.
"https://github.com/luisbg/rust-datetime" isn't packaged as a Cargo crate.
"https://github.com/rust-lang/rust/wiki/Lib-datetime" is discussion without any conclusions or actions.

Can we at least have an agreed internal representation of time/date, to which operations can later be added?

[emberian]

@John-Nagle https://github.com/lifthrasiir/rust-chrono

[John-Nagle]

OK, thanks. That should be mentioned at the Rust wiki.
It lacks date parsing functions. I'm writing parsing for the RFC3339 subset of ISO 8601, which is the form of timestamp found on email and RSS feeds.

[steveklabnik]

I'm pulling a massive triage effort to get us ready for 1.0. As part of this, I'm moving stuff that's wishlist-like to the RFCs repo, as that's where major new things should get discussed/prioritized.

This issue has been moved to the RFCs repo: rust-lang/rfcs#619

[John-Nagle]

It lacks date parsing functions. This is documented ("Advanced offset handling and date/time parsing is not yet supported (but is planned).") I happen to need RFC 822 date parsing ("Tue, 20 Jan 2015 17:35:20 -0800") but others may need other formats.

[lifthrasiir]

@John-Nagle If you are interested, please participate to chronotope/chrono#12.

[luisbg]

Sorry guys. I got very busy with interviews and a new job, and I couldn't finish my work on rust-datetime. Hopefully it can serve as a base or reference for future development in this topic.