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.
I've identified a problem. And I've identified a possible way to
solve it. There could be a problem with my solution, sure. But to
say we should do nothing at all doesn't not help solve the issue at hand.
Where did I say that? I suggested supplying a time zone to be used
during conversion.
The timezone
of the server, or of the web client, then displays the correct time.
So, yes, I agree that the process is broken. It's probably a java
issue itself that we have to work around.
-Adrian
On 6/16/2010 1:55 PM, Adam Heath wrote:
Adrian Crum wrote:
I agree that the scenario you describe can be a problem, but that
doesn't mean the seed data is broken.
I assume that if I import all the xml data files, over and over, that
new records will not be created. It'll just update existing records,
whatever they are. Changing the timezone should alter that.
-Adrian
On 6/16/2010 1:34 PM, Adam Heath wrote:
Any place that specifies a date in a seed xml *must* also specify a
timezone. If you do an install on one machine, then do a
dump/copy/import on another machine, that is in a different
timezone,
then reimport the original seed xml, the timestamps will not match.
What happens, is that there is no timezone on the fromDate fields.
The original import uses the timezone of the local machine as the
default in this case.
When the seed xml is reimported on the second machine, it uses the
default timezone of the second machine. If the timezones are
different, then the fromDate will be different as well, and you'll
get
duplicate records in the database.
The fix here is to update all the seed xml files to specify a
timezone. Probably using UTC would be the sensible approach.
