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.
