The code in ValueFactory.java does nothing, a simple return new LocalDateTime(value) does the same thing.
The problem with the LocalDateTime is the SQL timestamp is by definition an absolute point in time and that means it's calendar representation is time zone dependant. I think the LocalDate and LocalTime can work with my fix but for LocalDateTime, I would need to add a double time zone adjustment to UTC or GMT; convert to UTC on save and from UTC on read. LocalDate and LocalTime seems more easily handled but I need to test. I try to avoid timestamp except for usage like log entry timestamp where we want to know when something occurred. For local time, I prefer string columns, their behaviour is always predictable. Samuel Le 2013-11-19 à 11:27, Ramsey Gurley <[email protected]> a écrit : > In Wonder 6.1, I see: > > ValueFactory.java > > public static LocalDateTime jodaLocalDateTime(Date value) { > GregorianCalendar gc = new GregorianCalendar(GMT); > gc.setTime(value); > LocalDateTime ldt = new LocalDateTime(gc.getTimeInMillis()); > return ldt; > } > > ValueConversion.java > > public static Date jodaLocalDateTime(LocalDateTime value) { > GregorianCalendar gc = new GregorianCalendar(GMT); > gc.set(Calendar.YEAR, value.getYear()); > gc.set(Calendar.MONTH, value.getMonthOfYear() -1); > gc.set(Calendar.DAY_OF_MONTH, value.getDayOfMonth()); > gc.set(Calendar.HOUR_OF_DAY, value.getHourOfDay()); > gc.set(Calendar.MINUTE, value.getMinuteOfHour()); > gc.set(Calendar.SECOND, value.getSecondOfMinute()); > gc.set(Calendar.MILLISECOND, value.getMillisOfSecond()); > return gc.getTime(); > } > > Has someone changed that recently, or are you saying that is not working the > way I think it works? > > Ramsey > > On Nov 19, 2013, at 9:06 AM, Samuel Pelletier <[email protected]> wrote: > >> Hi, >> >> This issue confirm my doubts about the way JodaLocalxxx are saved. I have a >> branch in my repo with some correction in the Joda time attribute handling, >> the conversion in the save and read functions are not symmetric in the >> actual code. >> >> I also updated the JodaTime lib to latest with updated time zones. >> >> As I did not tested with LocalDateTime and LocalTime, the pull request is >> not created yet. If you want to test this code, it is on GitHub. >> >> The interesting part is is ValueConversion.java >> public static Date jodaLocalDateTime(LocalDateTime value) { >> Date javaDate = value.toDate(); >> return javaDate; >> } >> >> The old code switched the time zone to UTC before saving and JDBC was >> assuming a value with the current timezone. On read, the value was took from >> jdbc as is. >> >> Samuel >> >> >> Le 2013-11-15 à 10:27, John Huss <[email protected]> a écrit : >> >>> JDBC still relies on java.sql.Timestamp, etc, which uses the system's time >>> zone when saving and loading data. Usually the easiest solution is to set >>> the default time zone to UTC by adding a VM argument -Duser.timezone=UTC >>> >>> Then when you need to display date times you can choose a different time >>> zone for display purposes explicitly. >>> >>> >>> On Thu, Nov 14, 2013 at 10:51 PM, Jeffrey Schmitz <[email protected]> >>> wrote: >>> Hello List, >>> A simple question about a time value (as if any quesiton about >>> webobjects and time is simple :-)), I have a field I've defined using the >>> jodaLocalDateTime prototype. I was assuming that if I save the value >>> 2013-11-14T12:00:00.000 to my EO, the database would save exactly that, >>> using 12:00:00 for the time. However when I go to the database, the actual >>> time saved is 6:00:00, so obviously it is assuming the time I'm saving is >>> in Greenwich time and converting it to Local time. By the name, maybe that >>> makes sense, but I was thinking LocalTime meant time zone free. >>> >>> What makes this more maddening is that when I go to display the time from >>> my EO, it displays it as 6:00:00, so in essence, it's doing the conversion >>> on the save, but not on the retrieve. What am I missing here? >>> >>> Thanks! >>> Jeff >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list ([email protected]) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/webobjects-dev/johnthuss%40gmail.com >>> >>> This email sent to [email protected] >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list ([email protected]) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/webobjects-dev/samuel%40samkar.com >>> >>> This email sent to [email protected] >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/rgurley%40smarthealth.com >> >> This email sent to [email protected] >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
