Adrian Crum wrote: > On 6/16/2010 3:53 PM, Adam Heath wrote: >> 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. > > 1. Import existing seed data. Date-time values are referenced to > server's time zone. > 2. Export data, specifying date-time data is referenced to GMT. > 3. Import data on a server located in another time zone, specify > date-time data is referenced to GMT.
You aren't doing what I said. After moving the data to another timezone/server, import existing seed xml again. This is step 4. You'll end up with duplicate values stored in the database, because the default timezone from the server was used, which caused the calculate real time to be different. This problem can be seen relatively simply. Do an ant run-install. change timezone. do another ant run-install. > > The date-time data should be the same in both servers. > > I'm not sure what you mean by fixing the seed data. If you mean > specifying time zones in the seed data, then that will cause all kinds > of problems. One simple example I can think of is the Staff Meeting > recurring event in Work Effort. It is set for Monday at 10 AM - that is > clear in the seed data and in the documentation that references it. If a > GMT time zone is specified in the seed data file, then any server > outside of the GMT time zone will display the meeting at at the wrong time. >
