Re: joda LocalDateTime
Re: joda LocalDateTime
- Subject: Re: joda LocalDateTime
- From: Jeffrey Schmitz <email@hidden>
- Date: Thu, 08 Jan 2015 21:02:23 -0600
A little more digging on this...
Down in com.webobjects.jdbcadaptor._FrontBasePlugin class, if I comment out line 1825 in the formatValueForAttribute function (as shown below) , I am able to save the Timestamp value in the database, so it looks like Frontbase doesn't like the way this function is formatting he timezone part of a Timestamp value.
case FrontBaseTypes.FB_TimestampTZ: {
StringBuffer time = new StringBuffer("TIMESTAMP '");
Date d = (Date)eoattribute.adaptorValueByConvertingAttributeValue(obj);
SimpleDateFormat formatter = TIMESTAMP_FORMATTER.get();
formatter.format(d, time, new FieldPosition(0));
// time.append(getTimeZone(formatter.getTimeZone()));
time.append('\'');
return time.toString();
}
Jeff
> On Jan 8, 2015, at 2:44 PM, Jeffrey Schmitz <email@hidden> wrote:
>
> Samuel, Ramsey,
>
> Hi All,
> I’m using Frontbase, and an EOObject with a field defined with the Prototype jodaLocalDateTime has stopped working. Since I recently updated my Wonder frameworks I suspect that has something to do with it.
>
> Looking at the SLQ produced for an INSERT on a machine still running the older Wonder frameworks, and that still works, the format of the time field is specified as: TIMESTAMP '2015-01-08 13:00:00.000’
>
> Looking at the SQL produced using the new Wonder Frameworks, the same field in the INSERT is specified as: TIMESTAMP '2015-01-08 00:54:42.847+00:00’
>
> I’m using the java datatype of org.joda.time.LocalDateTime
>
> Could your last change described in this email chain have affected this, as I don't think I rolled it in until now?
>
> Here's the full INSERT commands being generated...
>
> Works with older Wonder frameowrks:
> "INSERT INTO "t_event"("c_display", "c_title", "c_game", "id", "c_tv", "poolID", "c_all_day", "c_date_time", "c_description", "c_location", "c_group") VALUES ('true', 'test joda time', NULL, 1000073, NULL, 1000099, 'false', TIMESTAMP '2015-01-08 13:00:00.000', 'abcde', 'bed', NULL)" withBindings: >
>
> Does not work new Wonder frameworks:
> INSERT INTO 't_event'('c_display', 'c_tv', 'c_date_time', 'entryID', 'c_location', 'c_game', 'c_all_day', 'poolID', 'c_title', 'id', 'c_description', 'c_group') VALUES ('false', NULL, TIMESTAMP '2015-01-08 00:54:42.847+00:00', 1000002, 'TBA', 0, 'false', 1000001, 'NCAA BBall Round 1 Game', 1000001, NULL, 0)" withBindings: >:
>
> Full Exception:
>
> INFO er.transaction.adaptor.Exceptions - Database Exception occured: com.webobjects.eoaccess.EOGeneralAdaptorException: EvaluateExpression failed: <com.webobjects.jdbcadaptor._FrontBasePlugIn$FrontbaseExpression: "INSERT INTO "t_event"("c_display", "c_tv", "c_date_time", "entryID", "c_location", "c_game", "c_all_day", "poolID", "c_title", "id", "c_description", "c_group") VALUES ('false', NULL, TIMESTAMP '2015-01-08 20:36:31.878+00:00', 1000002, 'TBA', 0, 'false', 1000001, 'NCAA BBall Round 1 Game', 1000001, NULL, 0)" withBindings: >:
> Next exception:SQL State:00000 -- error code: 231 -- msg: Semantic error 231. INSERT value doesn't match column: c_date_time.
> Next exception:SQL State:00000 -- error code: 485 -- msg: Semantic error 485. Near: INSERT INTO \"t_event\"(\"c_display\",\"c_tv\",\"c_date_time\",\"entryID\",\"c_location\",\"c_game\",\"c_all_day\",\"poolID\",\"c_title\",\"id\",\"c_description\",\"c_group\") VALUES('false',NULL,TIMESTAMP '2015-01-08 20:36:31.878+00:00',1000002,'TBA',0,'false',1000001,'NCAA BBall Round 1 Game',1000001,NULL,0);.
> Next exception:SQL State:00000 -- error code: 485 -- msg: Semantic error 485. Near: 0.
> Next exception:SQL State:40000 -- error code: 363 -- msg: Exception condition 363. Transaction rollback.
>
>
>> On Nov 21, 2013, at 3:58 PM, Samuel Pelletier <email@hidden> wrote:
>>
>> Ramsey,
>>
>> My tests with different databases (mySql, PostgreSql and FrontBase) are now all OK. I inserted and read back data with the 4 types with different time zone on my machine successfully. I needed to make sure the data was saved in an expected way for compatibility with others users of the data.
>>
>> This experience produced another pull request for FrontBase prototypes as FrontBase TIME and TIMESTAMP types are not behaving like the one in MySql and PostgreSql. I think Oracle does the same as PostgreSql. This difference was a nightmare before I saw it because I was fixing for a system to break another.
>>
>> I will look at the unit test later. I never touched them before, I need to understand how they works.
>>
>> I also created a pull request to update JodaTime to version 2.3.
>>
>> Samuel
>>
>> Le 2013-11-21 à 15:09, Ramsey Gurley <email@hidden> a écrit :
>>
>>>
>>> On Nov 21, 2013, at 10:02 AM, Samuel Pelletier <email@hidden> wrote:
>>>
>>>> Ramsey,
>>>>
>>>> The current code in the master branch is broken for LocalTime AND LocalDateTime unless your current time zone is GMT.
>>>
>>> I think it’s broken for GMT too on both of those.
>>>
>>>> I do not think the code should depend on the current application server time zone.
>>>
>>> Correct, it should work no matter the 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.
>>>
>>> For your own testing that’s great. I’d leave the databases out of any unit tests though. You know the converters should produce the same value before and after, so just test that.
>>>
>>>>
>>>> BTW, Have you ever tried to compute airplane travel time based on the local departure and arrival time?
>>>
>>> No, and I don’t envy anyone who has :D
>>>
>>>> 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
>
>
> _______________________________________________
> 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
_______________________________________________
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