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. I think the xml parser/dumper is broken. Timestamps should not be utilized there, instead any time is GMT/UTC(offset 0). 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. >>>> >> >>
