Adrian Crum wrote: > 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.
Timestamp to XML is correct; the timezone is in the output. XML to Timestamp is sometimes correct, but only if there is an actual timezone in the data. With no timezone, the actual parsed time(seconds since epoch + fractional) changes depending on the timezone the parsing took place in. Consider an import from xml, with no timezones, an xml dump, then a comparison of the 2 file sets. Ignoring any stamp date files, and fixing an ordering of rows, the files will not have the same values. >> 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. Just put a timezone on the value. I'm talking about values that currently have no timezone setting at all. If it has no timezone, the default is GMT, not whatever the local machine is set to. I've identified a problem. And I've identified a possible way to solve it. There could be a problem with my solution, sure. But to say we should do nothing at all doesn't not help solve the issue at hand. > >> 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. >>>>>> >>>> >>>> >> >>
