Yep, you’re right. LocalTime and LocalDateTime are broken. And I still hate
java dates :-) It should be the same in and out.
When you fix it, please include a unit test for ERXTest in the pull request
demonstrating it is fixed no matter the time zone.
Something like
public void testValueConversions() {
TimeZone defTz = TimeZone.getDefault();
TimeZone defNSTz = NSTimeZone.getDefault();
for(String id: TimeZone.getAvailableIDs()) {
TimeZone tz = TimeZone.getTimeZone(id);
TimeZone.setDefault(tz);
NSTimeZone.setDefault(tz);
LocalDateTime ldt = new LocalDateTime();
LocalDateTime converted =
ValueFactory.jodaLocalDateTime(ValueConversion.jodaLocalDateTime(ldt));
assertEquals(ldt, converted);
}
TimeZone.setDefault(defTz);
NSTimeZone.setDefault(defNSTz);
}
but testing all four of the Joda value converters, not just LocalDateTime.
Good catch. Thanks,
Ramsey
On Nov 19, 2013, at 9:27 AM, Ramsey Gurley <[email protected]> wrote:
> 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]
