Any way we can get this in clojure-contrib?
Matt Moriarity
working on a date library for Clojure since the built-in Java one is
kind of a mess. It's not totally complete, but I think it could be
quite useful. It supports getting the current date and time, and
creating dates based on input. It also has excellent date formatting
and parsing support, which allows users do define they're own custom
date formats as well as using the built-in java ones.
The code is here: http://gist.github.com/49656
I was wondering if this could get added to clojure-contrib. I'm not
really sure how things work for the project, but I figured this would
be the best place to ask. Dates are a pretty basic data structure, so
I think many would benefit from having this.
Matt Moriarity
Just so you know :)
Nick Vogel
Matt Moriarity
to add another dependency, since this is something so integral to the
language. I don't know what other people think, though. This was just
an informal decision on #clojure.
On Jan 23, 12:05 am, Nick Vogel <voge...@gmail.com> wrote:
> That sounds interesting; you might take a look at Joda
> library that people actually use for dates/times (I do know that Google uses
> it). Doing a quick search, it looks like Mark McGranaghan is working on a
> On Thu, Jan 22, 2009 at 11:51 PM, Matt Moriarity
lpetit
developers ?
Anyway, as far as I remember, one of the benefits of clojure running
on an existing VM (the JVM) is to leverage all the existing APIs.
Since the date/time support would be in clojure-contrib (and not
clojure-core), couldn't it make sense to have joda jar as an
explicitly required dependency.
And the design of you lib could carefully avoid exposing joda
internals, so that joda could remain an implementation detail (and
eventually be thrown away when you have the time to rewrite it) ?
My 0,02€,
--
Laurent
AndrewC.
> Interesting. Are u sure joda-time is so widely in usage among java
> developers ?
I believe there are moves afoot to get it included in the JDK sooner
or later.
https://jsr-310.dev.java.net/
Mark Volkmann
That's right. So eventually it won't be an extra dependency. For that
reason I think it would be much better to make the contrib date/time
functions delegate to the Joda Time library.
--
R. Mark Volkmann
Object Computing, Inc.
Chouser
It looks to me like this lib as it stands would allow me to go from
a date string (from a file or user input) or from the current date,
through some minimal calculations, and back out to a formatted string
without ever touching the underlying Java object directly. Why do I
care if Joda time is inside or not.
...except of course that every external dependency is an increased
burden on the users of any code I write. It seems likely that a
pretty substantial percentage of use cases could be handled in a way
that would allow either Java lib to be used underneath. That way I
would have no extra dependency now, or if I need Joda features could
use that instead.
--Chouser
Mark Volkmann
I think some reasons to use Joda Time instead of new code for
data/time calculations include:
1) Joda Time is already very well tested, so it's known to be good code.
2) Joda Time has much more functionality than what has been
implemented so far in Clojure. Having the Clojure code delegate to
Joda Time paves the way to easily add more of that functionality
later.
3) When Joda Time becomes a standard part of Java, the extra
dependency will go away.
4) Reimplementing Joda Time functionality consumes time that could be
better spent on other things.
Mark McGranaghan
library have a functional implementation, whereas the current built-in
Java classes tend to use non-functional/non-threadsafe mechanisms.
- Mark M.
On Fri, Jan 23, 2009 at 9:14 AM, Mark Volkmann
Chouser
<r.mark....@gmail.com> wrote:
>
> I think some reasons to use Joda Time instead of new code for
> data/time calculations include:
I'm not arguing for new date-time code. I'm arguing for a good clean
functional wrapper around code that already ships with Java. What
Matt has posted strikes me as a good start down that road.
--Chouser
Phil Hagelberg
> ...except of course that every external dependency is an increased
> burden on the users of any code I write. It seems likely that a
> pretty substantial percentage of use cases could be handled in a way
> that would allow either Java lib to be used underneath. That way I
> would have no extra dependency now, or if I need Joda features could
> use that instead.
This is exactly how I feel. Relying on code in contrib is no big deal,
but as soon as I read something about downloading an external jar file
and making sure it's on the classpath, I start to rethink whether I
*really* need that functionality in the first place... maybe I could
just wrap something built-in to the JVM. So why not start with that in
the first place?
If Joda gets included in the next JVM, that would be great. If a good
package manager that could automate these kinds of dependencies were
written and achieved wide use within the Clojure community, that would
be even better. But we need to consider the current situation. There's
definitely a need for The Simplest Thing That Could Possibly Work.
-Phil