Adrian Crum wrote: > On 6/17/2010 9:09 AM, Adam Heath wrote: >>> The seed data works fine. It has been working fine for years. It's the >>> process you're using that is the problem. >> >> Also, if my process is wrong, fine, that might be true. But just >> don't tell me it is wrong. Give me a way to do what I have describe >> countless times. > > I believe the reason for some of the confusion lies in the subject being > a moving target, or different subjects being blurred together. It might > help to make some clear distinctions: > > 1. Existing, out-of-the-box seed data works as expected. Date-time > values in the seed data are referenced to the server's time zone and > that data displays as intended or expected. Out-of-the-box seed data is > not broken - it has been working fine for years. > > 2. Entity data in XML format that contains date-time data will cause > problems if it is shared by servers in different time zones. The reason > is because no time zone is specified in the XML file, so each server > will reference date-time values to its own time zone. We need a way to > specify a time zone in the XML data so that each server will reference > the same time zone when importing the data. > > 3. Developers who wish to share entity data in XML format between > servers in different time zones will need to define a process that > specifies a time zone to be shared, and then ensure the shared XML data > contains the specified time zone. In other words, the specified time > zone is an anchor or key - all shared XML data uses that time zone. > > To summarize what I've been saying: > > 1. You have identified a problem in sharing XML data that contains > date-time values and I agree it needs to be fixed. I suggest we specify > a time zone in the XML files, and if no time zone is specified, the > server's time zone is used. > > 2. The existing, out-of-the-box seed data files work fine. Please do not > specify time zones in the existing seed data files because that will > break a lot of existing code.
This is wrong. Existing seed data *is* broken. user_login_id | group_id | from_date | thru_date | last_updated_stamp | last_updated_tx_stamp | created_stamp | created_tx_stamp ---------------+-----------+------------------------+-----------+----------------------------+----------------------------+----------------------------+---------------------------- system | FULLADMIN | 2001-01-01 13:00:00-05 | | 2010-06-13 22:25:38.727-04 | 2010-06-13 22:25:38.664-04 | 2010-06-13 22:25:38.727-04 | 2010-06-13 22:25:38.664-04 system | FULLADMIN | 2001-01-01 12:00:00-05 | | 2010-06-15 20:30:20.83-04 | 2010-06-15 20:30:20.723-04 | 2010-06-15 20:30:20.83-04 | 2010-06-15 20:30:20.723-04 (3 rows) This is output from psql, of UserLoginSecurityGroup. Note the 1 hour difference on the fromDate. On 06-13, I imported all seed xml in ofbiz on a machine in CDT. I then did a pg_dump, copied the file to a machine in EDT, imported it. Then, did *just* a seed import on the new machine. No seed data was actually changed. I now have duplicate records. > 3. If you follow my suggestions and you're still having problems, then > there is something wrong in the process you're using. > > I'm not trying to be argumentative or aloof - I'm really trying to help. > I just don't know how to make it any simpler. > > -Adrian
