[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
wrote:
>
> 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 wrote: > > > > 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?
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 wrote: > > 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 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 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. > >> > >> > >> > >> 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). > >> > >> > >> > >> 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 > >> wrote: > >> > >> > >> > >> > >> > >> > 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'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 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 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. >> >> >> >> 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). >> >> >> >> 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 >> wrote: >> >> >> >> >> >> > 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?
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 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. > > > > 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). > > > > 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 > wrote: > > > > > > > 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. 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). 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 wrote: > > 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 -~--~~~~--~~--~--~---
