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]
