[Lift] Re: MappedDateTime - Do we have a Date? Or is it a timestamp?
Thanks Jorge! We just started using JodaTime and it's definitely everything we wanted from a Time API. Good Find!!! On Tue, Mar 31, 2009 at 8:31 PM, Kris Nuttycombe kris.nuttyco...@gmail.comwrote: 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 On Tue, Mar 31, 2009 at 1:54 PM, TylerWeir tyler.w...@gmail.com wrote: 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.comwrote: 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: MappedDateTime - Do we have a Date? Or is it a timestamp?
On Tue, Mar 31, 2009 at 11:10 PM, Timothy Perrett timo...@getintheloop.euwrote: 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... java.text.Format horror SimpleDateFormat horror... -- Viktor Klang Senior Systems Analyst --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: MappedDateTime - Do we have a Date? Or is it a timestamp?
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
On Tue, Mar 31, 2009 at 12:58 PM, Clemens Oertel
clemens.oer...@gmail.comwrote:
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
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: MappedDateTime - Do we have a Date? Or is it a timestamp?
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.comwrote: 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: MappedDateTime - Do we have a Date? Or is it a timestamp?
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.comwrote: 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: MappedDateTime - Do we have a Date? Or is it a timestamp?
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... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: MappedDateTime - Do we have a Date? Or is it a timestamp?
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 On Tue, Mar 31, 2009 at 1:54 PM, TylerWeir tyler.w...@gmail.com wrote: 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.comwrote: 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
