Re: joda LocalDateTime
Re: joda LocalDateTime
- Subject: Re: joda LocalDateTime
- From: Samuel Pelletier <email@hidden>
- Date: Thu, 21 Nov 2013 17:02:39 +0000
Ramsey,
The current code in the master branch is broken for LocalTime AND LocalDateTime unless your current time zone is GMT. I do not think the code should depend on the current application server time zone. Here is my very simple test code.
The good news is I think my current fix will not broke your data because I convert back and from GMT. I want to test a complete run trip with other database and change my computer time zone, actually, it works with FrontBase.
BTW, Have you ever tried to compute airplane travel time based on the local departure and arrival time? I still have bad dreams about that… just find the airport time zone was crazy at that time.
Samuel
LocalTime time1 = new LocalTime(12, 0, 0);
Date javaTime = ValueConversion.jodaLocalTime(time1);
LocalTime time2 = ValueFactory.jodaLocalTime(javaTime);
if (time1.equals(time2) == false) {
failed = true;
}
LocalDate date1 = new LocalDate(2012, 1, 1);
Date javaDate = ValueConversion.jodaLocalDate(date1);
LocalDate date2 = ValueFactory.jodaLocalDate(javaDate);
if (date1.equals(date2) == false) {
failed = true;
}
LocalDateTime localDateTime1 = new LocalDateTime(2012, 1, 1, 12, 0, 0);
Date javaLocalDateTime = ValueConversion.jodaLocalDateTime(localDateTime1);
LocalDateTime localDateTime2 = ValueFactory.jodaLocalDateTime(javaLocalDateTime);
if (localDateTime1.equals(localDateTime2) == false) {
failed = true;
}
DateTime dateTime1 = new DateTime(2012, 1, 1, 12, 0, 0);
Date javaDateTime = ValueConversion.jodaDateTime(dateTime1);
DateTime dateTime2 = ValueFactory.jodaDateTime(javaDateTime);
if (dateTime1.equals(dateTime2) == false) {
failed = true;
}
Le 2013-11-19 à 21:43, Ramsey Gurley <email@hidden> a écrit :
>
> On Nov 19, 2013, at 12:12 PM, Samuel Pelletier <email@hidden> wrote:
>
>> 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
>
> LocalDate and DateTime works based on a modification of the test code I attached. Value in == value out. Feel free to simplify it if the Calendar stuff is not required. Just don’t break it :-) I use those two.
>
>> 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
>
> I hate strings that need to conform to a certain format. It never fails. Someone always inserts something poorly formatted or a F'in magic string in the column.
>
> is_active
> “TRUE”
> “FALSE”
> “F”
> “YES"
> “MAYBE”
>
> happy_hour
> “18:00:00”
> “99:99:99”
> “noon"
> “Gerald”
> “CUSTOM"
>
> I prefer to use the correct value type for the value being stored. Correct value types prevent all sorts of clever tricks. You see that preference of mine reflected in the existing prototypes. For postgres at least, the external types are the correct ones for the datastore. LocalTime uses time. LocalDate uses date. LocalDateTime and DateTime use timestamp. For other DBs, IDGAF so much :-)
>
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden