Re: dates in seed xml files are very broken

[Adrian Crum]

On 6/17/2010 8:37 AM, Adam Heath wrote:
Adrian Crum wrote:
--- 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.

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 seed data works fine. It has been working fine for years. It's the 
process you're using that is the problem.

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