dates in seed xml files are very broken

[Adam Heath-2]

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.

[Adrian Crum]

I agree that the scenario you describe can be a problem, but that
doesn't mean the seed data is broken.

-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.
>

[BJ Freeman]

if you got that far it should be all four time fields.
however I don't see the need even with sync to do this.

=========================
BJ Freeman
http://bjfreeman.elance.com
Strategic Power Office with Supplier Automation  <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com  <http://www.specialtymarket.com/>

Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man
Linkedin
<http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro>


Adam Heath sent the following on 6/16/2010 1:34 PM:

> 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.
>

[Adam Heath-2]

BJ Freeman wrote:
>
> if you got that far it should be all four time fields.
> however I don't see the need even with sync to do this.

huh?

>
> =========================
> BJ Freeman
> http://bjfreeman.elance.com
> Strategic Power Office with Supplier Automation
> <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
> Specialtymarket.com  <http://www.specialtymarket.com/>
>
> Systems Integrator-- Glad to Assist
>
> Chat  Y! messenger: bjfr33man
> Linkedin
> <http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro>
>
>
>
> Adam Heath sent the following on 6/16/2010 1:34 PM:
>> 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.
>>
>

[Adam Heath-2]

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.
>>

[Adrian Crum]

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?

-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.
>>>
>
>

[Adam Heath-2]

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.

I think the xml parser/dumper is broken.  Timestamps should not be
utilized there, instead any time is GMT/UTC(offset 0).  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.
>>>>
>>
>>

[Adrian Crum]

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.

> 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.

> 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.
>>>>>
>>>
>>>
>
>

[Adam Heath-2]

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.

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.

>
>> 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.
>>>>>>
>>>>
>>>>
>>
>>

[Adrian Crum]

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.

> 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.
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>

[Adrian Crum]

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.
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
>

[Adam Heath-2]

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.

>
>>
>>> 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.
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>>

[Adrian Crum]

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.

>
>>
>>>
>>>> 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.
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>
>

[Adam Heath-2]

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.

[Adrian Crum]

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.

[Adam Heath-2]

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.

[Adrian Crum]

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.

[Adam Heath-2]

Adrian Crum 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.

You aren't doing what I said.  After moving the data to another
timezone/server, import existing seed xml again.  This is step 4.

You'll end up with duplicate values stored in the database, because
the default timezone from the server was used, which caused the
calculate real time to be different.

This problem can be seen relatively simply.  Do an ant run-install.
change timezone.  do another ant run-install.

>
> 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.
>

[Adrian Crum-2]

--- On Wed, 6/16/10, Adrian Crum <[hidden email]> 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.

[Adam Heath-2]

Adrian Crum wrote:

> --- On Wed, 6/16/10, Adrian Crum <[hidden email]> 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?

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 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.



>
>
>
>