Apologies up front if this is in fact a mysql rather than a turbine
question.
Environments:
Development - Win2k, turbine 2.1, mysql 3.23.42-nt
Production - Linux, turbine 2.1, mysql 3.23.32
A bunch of my tables include START_DATE and END_DATE columns that are
defined as type="DATE" in my schema, becoming DATETIME for mysql.
Values for these columns are entered as Strings and converted to dates using
(new SimpleDateFormat("d/MM/yyyy")).parse()
The problem I am experiencing occurs when the date entered falls in daylight
savings time (DST). For the examples below my locale is "en-AU".
A non-DST Date is expressed in GMT+10 - e.g.:
31/05/2002 becomes: Fri May 31 00:00:00 GMT+10:00 2002
For DST times the offset to GMT is simply adjusted automatically by the JVM
- e.g.:
31/12/9999 becomes: Fri Dec 31 00:00:00 GMT+11:00 9999
Note that this isn't just an oddity of 9999-12-32, it occurs for all DST
dates.
The problem is that when these hit the database I get a different result on
my development and production systems. On development I get:
2002-05-31 00:00:00
9999-12-31 00:00:00
But on production I get:
2002-05-31 00:00:00
9999-12-30 23:00:00 <- yikes!
This causes a date creep backwards whenever the record is updates - i.e. It
will be read as 9999-12-30, but later updated to 9999-12-29 23:00:00.
>From what I can tell the problem must be a mysql issue - on one environment
it seems to be ignoring the timezone difference for the DST date but on the
other it is catering for it.
Have others experienced this kind of problem? Know of a solution?
If I can get the two mysql instances to behave consistently then I can
correct the date after I parse it. The most annoying aspect of this problem
is that I only want a Date but I am having to muck around with the time!
Thanks in advance for any advise offered.
Scott
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
