--- On Wed, 6/16/10, Adrian Crum <adri...@hlmksw.com> 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. > > 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.
Actually, this is a bad example - the Staff Meeting temporal expression does not contain a date-time value. A better example would be the recurring jobs that use a Frequency temporal expression.
