> Maybe, since Roman wrote " ... write data into the
> database using local time zone", a proper name for the
> behaviour would be "write_uses_local_timezone" ... but
> that doen't seem to be the point.

I'm not happy with the name invert_time_zone, but I also do not want it to
be too long. The shorter, the better. So, I'm open to suggestions. :)

So far we have

invert_time_zone
mysql_timezone_interpretation
write_uses_local_timezone

> Just one more question : I have an old app that works
> flawlessly since a couple of years now. It uses odbc
> way of writing dates and timestamp in the inserts and
> updates statements (no prepared statement is used ) .
> What happens to thoose sql statements in the new way ?
> eg :
> "Insert into my_table values (1,{d '2004-02-08'
> },'test value--date')"
> "Insert into my_table2 values (1,{t '2004-02-08
> 01:57:23' },'test value--timestamp')"

Nothing. These statements are sent without a change to the database server
and are stored as they are (escaped syntax does not contain time zone, nor
does the TIMESTAMP data type on the server).

> Theese are obviously values determined by the client .
> Do you think I will have to use the "old style" way of
> handling dates ?

No. But even if you specify this flag, it will not affect the execution
flow. This flag is related only to the setTimestamp(int, Timestamp,
Calendar) (and, of course, getTimestamp(int, Calendar)).

Roman