IIRC, scala-time is a wrapper over joda-time anyway
I vote +100 for moving away from Java's dates and all the associated
problems. 0-indexed month numbers and thread-unsafe parsing are just the
tip of that particular iceberg...
On Mon, Sep 14, 2009 at 5:23 PM, Derek Chen-Becker
Anyone else care to comment? Joda Time and Scala Time are both licensed
Apache, so I don't think there would be any issues there, but this would be
a significant change. Would anyone here strongly prefer to stay with
java.util.Date?
Derek
On Sat, Sep 12, 2009 at 12:56 PM, Charles F. Munat
java.util.Date isnt thread safe so its probably best we move away from
that anyways...
Cheers, Tim
On 14 Sep 2009, at 17:23, Derek Chen-Becker wrote:
Anyone else care to comment? Joda Time and Scala Time are both
licensed Apache, so I don't think there would be any issues there,
but
Also, the LiftRules.parseDate function currently does DateTime
parsing, so I would have to make a breaking change to rename it to
parseDateTime and add new parseDate and parseTime (and associated
format methods). Thoughts?
I think this is the right solution. Don't know how much will
+1 for joda or scala time if it's not too disruptive
Chas.
Indrajit Raychaudhuri wrote:
Also, the LiftRules.parseDate function currently does DateTime
parsing, so I would have to make a breaking change to rename it to
parseDateTime and add new parseDate and parseTime (and associated
format
Of course, now that I'm actually digging into the code, it really makes me
want to switch to using Joda Time :). Also, the LiftRules.parseDate function
currently does DateTime parsing, so I would have to make a breaking change
to rename it to parseDateTime and add new parseDate and parseTime (and
OK, this is different than the code I originally wrote. In 1.0.1 it's this:
http://github.com/dpp/liftweb/blob/aec338c97648ea700de7a14b495b8be6b374153b/lift-mapper/src/main/scala/net/liftweb/mapper/MappedDate.scala
I'm not sure who made that change, but I think that we want something in the
OK, maybe I misread Naftoli's email but it sounded like he didn't want
global parsers, e.g. a per-field parser. I agree on the Date/DateTime/Time
split. I can add some of those to LiftRules and TimeHelpers.
Derek
On Thu, Sep 10, 2009 at 1:04 PM, Jeppe Nejsum Madsen je...@ingolfs.dkwrote:
Derek Chen-Becker dchenbec...@gmail.com writes:
OK, maybe I misread Naftoli's email but it sounded like he didn't want
global parsers, e.g. a per-field parser.
Re-reading his email I think you're right :-) But that should be solved
with your solution where you can override the format on a
Having an overridable toDate on the MappedXX that only defaults to the
_corresponding_ global, as Jeppe said, would provide that ability too.
Although the advantage of using a DateFormat over a def toDate is simplicity of
replacement. (Maybe it should be a function, not a method, and there
It should be working currently with more than Strings. The definition of
setFromAny is:
override def setFromAny(f : Any): Date = toDate(f).map(d =
this.set(d)).openOr(this.is)
where toDate comes from net.liftweb.util.TimeHelpers:
/** @return a Full(date) or a failure if the input couldn't be
Derek Chen-Becker dchenbec...@gmail.com writes:
It should be working currently with more than Strings. The definition of
setFromAny is:
override def setFromAny(f : Any): Date = toDate(f).map(d =
this.set(d)).openOr(this.is)
This, I think, is from MappedTime. MappedDate ( MappedDateTime)
I asked about this in another thread, and no one responded.
Why do all three date fields use a global DateFormat to format and parse dates?
Besides the fact that they should each use a different DateFormat from each
other since they represent different subsets of the information in a
13 matches
Mail list logo
