Adrian Crum wrote: > On 6/16/2010 3:03 PM, Adrian Crum wrote: >> On 6/16/2010 2:56 PM, Adam Heath wrote: >>> 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. >> >> That would work. I was picturing a time-zone attribute in the entity >> element. > > Oops, entity-engine-xml element.
Both then? timezone-in-value wins. then fallback on timezone in entity-engine-xml. then GMT. > >> >>> 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. >> >> Where did I say that? I suggested supplying a time zone to be used >> during conversion. >> >>>>> 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. >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> >>
