MappedDateTime - Do we have a Date? Or is it a timestamp?

18 views
Skip to first unread message

Clemens Oertel

unread,
Mar 31, 2009, 2:58:36 PM3/31/09
to lif...@googlegroups.com
While trying to figure out why my MappedDateTime fields get stored in
the DB with all the time info set to 0, I noticed the following:

MappedDateTime (v. 1.0) "claims" to be a TimeStamp: def targetSQLType
= Types.TIMESTAMP. However, it uses java.sql.Date for its JDBC-
friendly converted version, not java.sql.TimeStamp. If I read the
java.sql.Date documentation correctly, java.sql.Date does set all time
information to 0, since the SQL DATE type only stores dates, by no
times.

Any comment whether this might have something to do with me losing my
time would be appreciated.

Best,
Clemens

Jorge Ortiz

unread,
Mar 31, 2009, 3:21:21 PM3/31/09
to lif...@googlegroups.com
I was on IRC trying to help Clemens with this. The name (MappedDateTime), targetSQLType (java.sql.Types.TIMESTAMP), and type (extends MappedField[java.util.Date, _]) of this class suggests millisecond precision (java.sql.Timestamp and java.util.Date have millisecond precision). However, methods jdbcFriendly and real_convertToJDBCFriendly use java.sql.Date, which has only day precision.

If the intent is day precision, then calling the class DateTime is probably misleading. If the intent is millisecond precision, then we have a bug.

<rant>

Which brings up the larger issue of the brokennes of the Java Date/Time API. Java 7 will hopefully be getting a newer/better one, but for those of us stuck on Java 5/6, Joda Time is much preferable to the native Date/Time API. It more clearly represents foundational concepts like instants (March 31, 2009 at 12:15.000pm UTC), partials (March 3 or 7:15pm), intervals (the space between two instants), durations (1000 milliseconds), periods (1 month), and chronologies (calendar systems). It's also completely immutable (oh, you didn't know java.util.Calendar isn't thread-safe? you're lucky to have never had to track down that bug).

</rant>

Sigh... it's probably too big of a breaking change to rip out Java Date/Time from Mapper and Helpers and replace it with Joda Time, but one can dream...

--j

TylerWeir

unread,
Mar 31, 2009, 3:54:55 PM3/31/09
to Lift
For an internal project I used JodaTime, twas a dream.

I have switched to using MappedLong along with Unix time for dates
now.

( hooray for ancedotes! )

On Mar 31, 3:21 pm, Jorge Ortiz <jorge.or...@gmail.com> wrote:
> I was on IRC trying to help Clemens with this. The name (MappedDateTime),
> targetSQLType (java.sql.Types.TIMESTAMP), and type (extends
> MappedField[java.util.Date, _]) of this class suggests millisecond precision
> (java.sql.Timestamp and java.util.Date have millisecond precision). However,
> methods jdbcFriendly and real_convertToJDBCFriendly use java.sql.Date, which
> has only day precision.
>
> If the intent is day precision, then calling the class DateTime is probably
> misleading. If the intent is millisecond precision, then we have a bug.
>
> <rant>
>
> Which brings up the larger issue of the brokennes of the Java Date/Time API.
> Java 7 will hopefully be getting a newer/better one, but for those of us
> stuck on Java 5/6, Joda Time is much preferable to the native Date/Time API.
> It more clearly represents foundational concepts like instants (March 31,
> 2009 at 12:15.000pm UTC), partials (March 3 or 7:15pm), intervals (the space
> between two instants), durations (1000 milliseconds), periods (1 month), and
> chronologies (calendar systems). It's also completely immutable (oh, you
> didn't know java.util.Calendar isn't thread-safe? you're lucky to have never
> had to track down that bug).
>
> </rant>
>
> Sigh... it's probably too big of a breaking change to rip out Java Date/Time
> from Mapper and Helpers and replace it with Joda Time, but one can dream...
>
> --j
>
> On Tue, Mar 31, 2009 at 11:58 AM, Clemens Oertel
> <clemens.oer...@gmail.com>wrote:

Timothy Perrett

unread,
Mar 31, 2009, 5:10:54 PM3/31/09
to Lift

> chronologies (calendar systems). It's also completely immutable (oh, you
> didn't know java.util.Calendar isn't thread-safe? you're lucky to have never
> had to track down that bug).

LOL!!! Its not thread safe!? Thats somewhat of an oversight isnt it...

Kris Nuttycombe

unread,
Mar 31, 2009, 8:31:00 PM3/31/09
to lif...@googlegroups.com
I'm also using joda-time, and very pleased with it. In fact, I use it
in my Lift project - via JPA with the provided Hibernate extensions
for mapping of DateTime, Period, etc.

Kris

Josh Suereth

unread,
Apr 1, 2009, 8:17:52 AM4/1/09
to lif...@googlegroups.com
Thanks Jorge!  We just started using JodaTime and it's definitely everything we wanted from a Time API.   Good Find!!!

Viktor Klang

unread,
Apr 1, 2009, 8:22:42 AM4/1/09
to lif...@googlegroups.com

java.text.Format.... horror.... SimpleDateFormat.... horror...
 






--
Viktor Klang
Senior Systems Analyst

Derek Chen-Becker

unread,
Apr 1, 2009, 8:50:53 AM4/1/09
to lif...@googlegroups.com
Well, I guess this bug needs updated:

http://liftweb.lighthouseapp.com/projects/26102-lift/tickets/28-mappeddatetime-does-not-store-time-portion-in-derby-10420

I would vote for JodaTime. Having written some scheduling apps in Java all I can say about java.util.{Date,Calender} is WTF?

Derek
Reply all
Reply to author
Forward
0 new messages