Adrian Crum wrote: > On 6/17/2010 8:37 AM, Adam Heath wrote: >> Adrian Crum wrote: >>> --- On Wed, 6/16/10, Adrian Crum<[email protected]> 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. >> >> True, but lets expand on that. >> >> Let's say you have a time period definition, start work at 9am Monday >> morning, and stop work at 5pm Monday afternoon. Let's say such a >> definition is entered into seed xml somewhere. And lets then say that >> the 9am/5pm time frame is for an EST(United States Eastern). >> >> What happens when the server maintaining such a time period is hosted >> in California? > > The California server loads seed data in its time zone and displays the > data in its time zone - 9AM to 5PM will be displayed as 9AM to 5PM. A > New York server loads seed data in its time zone and displays the data > in its time zone - 9AM to 5PM will be displayed as 9AM to 5PM. A New > Zealand server loads seed data in its time zone and displays the data in > its time zone - 9AM to 5PM will be displayed as 9AM to 5PM.
The time period above is for EST, not PST. I was trying to show that it was a large company, with a presence in many places all over the world. To make everything work in such a situation, the initial data load *must* contain timezones. And if you are then s uggesting that the timestamps for such entities in this situation must have timezones, but then other values don't need them, then that way lies madness. > The seed data works fine. It has been working fine for years. It's the > process you're using that is the problem. The process I am using is fine. Ofbiz is growing, becoming bigger. Just because no one has discovered this problem until now, does not mean it doesn't exist, and shouldn't be fixed. If we were to take your way of thinking to it's conclusion, we would never be able to implement new features. I'm certain you don't mean that. >> If the above time period is encoded as timestamps, then the system is >> broken as designed. >> >> If, however, the time period is encoded as meta-data, then there is no >> problem. >> >> So, any timestamps that are used to encoded such extremely local >> specific time periods, needs to be fixed to *not* use timestamps. >> >> Another way of looking at the original problem, is that all time is >> the same. 5pm EST is the same as 4pm CST. But with the way the >> current seed data is configured, the value will be different depending >> on a when/where you import it. > > The Timestamp value will change depending on the time zone, but what is > displayed will remain the same. If the seed data is intended to contain > 5PM, then 5PM is what you will get - no matter where you load it. > >> The seed data also has problems when dealing with daylight savings >> time. Some timezones have such a feature, and then there are local >> rules that specify when dst actually happens. This was due to not >> forcing a timezone during import, and not forcing a timezone when >> testing. > > Seed data for testing is another issue, and I agree that there is a > problem there. > > -Adrian
