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.
