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

Visto 18 veces
Saltar al primer mensaje no leído

Clemens Oertel

no leída,
31 mar 2009, 14:58:3631/3/09
a 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

no leída,
31 mar 2009, 15:21:2131/3/09
a 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

no leída,
31 mar 2009, 15:54:5531/3/09
a 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

no leída,
31 mar 2009, 17:10:5431/3/09
a 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

no leída,
31 mar 2009, 20:31:0031/3/09
a 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

no leída,
1 abr 2009, 8:17:521/4/09
a 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

no leída,
1 abr 2009, 8:22:421/4/09
a lif...@googlegroups.com

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






--
Viktor Klang
Senior Systems Analyst

Derek Chen-Becker

no leída,
1 abr 2009, 8:50:531/4/09
a 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
Responder a todos
Responder al autor
Reenviar
0 mensajes nuevos