On 6/16/2010 2:03 PM, Adam Heath wrote:
Adrian Crum wrote:
It sounds to me like the process is broken, not the data. Why not
specify a time zone along with a file name when importing/exporting?
Because you may have multiple timezones in the data.
Timezones are not actually part of the data. They are only utilized
during display, by adjusting the raw time by some offset amount.
Time zones are used in parsing the XML date-time string into a
Timestamp, and in converting a Timestamp to XML.
I think the xml parser/dumper is broken. Timestamps should not be
utilized there, instead any time is GMT/UTC(offset 0).
That would solve your problem, but now you've made life hard on everyone
else. If I want to create my own seed data, I have to convert all of my
date-time data to GMT before entering it.
The timezone
of the server, or of the web client, then displays the correct time.
So, yes, I agree that the process is broken. It's probably a java
issue itself that we have to work around.
-Adrian
On 6/16/2010 1:55 PM, Adam Heath wrote:
Adrian Crum wrote:
I agree that the scenario you describe can be a problem, but that
doesn't mean the seed data is broken.
I assume that if I import all the xml data files, over and over, that
new records will not be created. It'll just update existing records,
whatever they are. Changing the timezone should alter that.
-Adrian
On 6/16/2010 1:34 PM, Adam Heath wrote:
Any place that specifies a date in a seed xml *must* also specify a
timezone. If you do an install on one machine, then do a
dump/copy/import on another machine, that is in a different timezone,
then reimport the original seed xml, the timestamps will not match.
What happens, is that there is no timezone on the fromDate fields.
The original import uses the timezone of the local machine as the
default in this case.
When the seed xml is reimported on the second machine, it uses the
default timezone of the second machine. If the timezones are
different, then the fromDate will be different as well, and you'll get
duplicate records in the database.
The fix here is to update all the seed xml files to specify a
timezone. Probably using UTC would be the sensible approach.
