Adrian Crum wrote: > On 6/16/2010 3:40 PM, Adam Heath wrote: >> Adrian Crum wrote: >>> On 6/16/2010 3:24 PM, Adam Heath wrote: >>>> 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. >>> >>> Time zone in value first, then time zone attribute in entity-engine-xml >>> element, then server's time zone (to preserve backward compatibility). >>> If you want to reference your data to GMT, then you can do that in the >>> entity-engine-xml attribute. >>> >>> It's flexible and it doesn't break any existing code. >> >> After adding support for parsing all this data, I would still end up >> changing the existing xml data files that ofbiz ships by default, >> however. > > Why? I think everyone is used to seed/demo data being referenced to > their own time zone.
Because it's a bug. The data is not specified fully. An import/dump cycyle will not have the same values(the dumped file has timezone information in it). An import of seed, change timezone(or copy the dataset to a different machine in a different timezone), and import of seed again(possibly after some minor seed upgrade) causes duplicate entries. Namely, PartyContactMech will have 2 values, because the hour was off. It's a bug, it should be fixed.
