Fix FrontBase prototypes for correct time zone handling of Joda Time

[spelletier]

To make FrontBase behave like mySql and PostgreSql, we need to use TIME WITH TIME ZONE and TIMESTAMP WITH TIME ZONE columns. With regular types, values are time zone dependant.

[darkv]

Hi Samuel,

can you elaborate on this. Why is your prototype change making FrontBase behave like MySQL and PostgreSQL? Looking at their prototypes there is no time zone either and looking at the JodaTime javadocs there is the statement

LocalDateTime is an unmodifiable datetime class representing a datetime without a time zone.

So at first sight it doesn't make sense to use the time zone dependent SQL data types or if it is legitimate then shouldn't the prototypes for all the other database be corrected too?

[spelletier]

This is a complex subject. My goal was to obtain this behaviour: LocalTime and LocalDateTime should always display the same date and time even after a database or app server time zone change. That was not the case before.

There is many counter intuitive things involved and the only way to make sure thing are OK is to test by changing the app server time zone with the same data. Some things I discovered in this long process:

• mySql does not handle time zone at all, everything is considered local.
• PostgreSql has a data type that handle time zone but it is not used in the prototypes.
• FrontBase implemented the standard as usual but others did not.
• The JDBC API use java Date for all date and time data and java Date does not contain time zone information. This is a mess.
• I also corrected the Joda Date value converters because they where wrongs with all databases after a time zone change on the app server.

Here is the message I sent to Geert to make sure I was OK:

I'm working with time for a project and after trying to understand how time is supposed to be handled by database, I found that FB seems to have a different behaviour if I compare to other SQL databases. I tried MySql and PostgreSql and the Oracle doc seems to indicate Oracle behave like the 2 others.

The 3 others consider TIME and TIMESTAMP as local time, i.e. the value returned is always the same for all client time zone. So, a row with TIME '12:00:00' is always fetched with TIME '12:00:00' for all driver client time zone. Same apply to TIMESTAMP columns.

FrontBase adjust the time value with the client zone. If I insert TIME '12:00:00' with a client in GMT-5, it is fetched as TIME '18:00:00' for GMT+1.

After some tests, I figured out that if I use TIME WITH TIME ZONE and TIMESTAMP WITH TIME ZONE, the behaviour is now the same as the others.

I do not know if this intentional because the standard is not clear or not correctly implemented on other for legacy support or it is an error so I ask the question: is this was the expected behaviour?

The answer was:

Yes, this is the intended behavior and and behavior we have spend quite some time on over the years to get right :o)

I hope this help.

[darkv]

Thanks for your detailed response. Now that makes much more sense.

[rkiddy]

Dare I say, since this is a complex subject, can we include tests in what you are submitting? I know. Just crazy talk, yes? O well. :-)

[spelletier]

Crazy talk... To test the validity of this, you need a database server and at least 2 clients on different time zone, quite a complex setup.
BTW, prototypes are just attributes templates, no code involved.

[rkiddy]

(sigh) I know. I just wish it bothered more people that it is so hard to set up database-specific tests for wonder. Never mind. Going back to my corner to sulk. :-)

[paulhoadley]

Just quickly, Johann writes:

shouldn't the prototypes for all the other database be corrected too?

I know you're just putting the question out there, but I'd be very reluctant to touch the PostgreSQL prototypes. This area is like a minefield, and we have a setup that works perfectly with the status quo. We run all our appservers and databases in UTC to eliminate this entire "server timezone changing" class of problems, and it's been pretty solid for some time now.

[spelletier]

It may be tricky to touch them but maybe not, need to test. I do not know the release history of PostgreSQL but the timestamp (not qualified) date type changed with release 7.3. From their documentation:

Note: The SQL standard requires that writing just timestamp be equivalent to timestamp without time zone, and PostgreSQL honors that behavior. (Releases prior to 7.3 treated it as timestamp with time zone.) timestamptz is accepted as an abbreviation for timestamp with time zone; this is a PostgreSQL extension.

I have no idea when this occur in time and how existing database where or where not adjusted.

[darkv]

I know you're just putting the question out there, but I'd be very reluctant to touch the PostgreSQL prototypes.

Yes, I know what such kind of proposals caused trouble on the mailing list in the (far) past but here that already happened for FrontBase. This was geared more towards “are the prototypes for MySQL and PostgreSQL already correct or do I have to be cautious when I start using joda with these databases”.

Correcting prototypes could perhaps be something for Wonder 7 though where a break and manual update coming from Wonder ≤ 6 would be ok. Besides that everyone should have his/her own prototype model, shouldn't they? ;)