Adrian Crum wrote:
> On 6/17/2010 10:23 AM, Adam Heath wrote:
>> Adrian Crum wrote:
>>> On 6/17/2010 10:10 AM, Ean Schuessler wrote:
>>>> Adrian Crum wrote:
>>>>> The seed data works fine. It has been working fine for years. It's the
>>>>> process you're using that is the problem.
>>>> Just because something has been broken for a long time does not mean it
>>>> is fixed. We have found numerous long-standing problems that simply
>>>> have
>>>> never been addressed. I'm sure you have found your share as well.
>>>
>>> Someone please prove to me the existing seed data is broken. I can prove
>>> that it isn't.
>>>
>>> Using Adam's example...
>>>
>>> In UserDemoData.xml:
>>>
>>> <UserLoginSecurityGroup groupId="FULLADMIN" userLoginId="admin"
>>> fromDate="2001-01-01 12:00:00.0"/>
>>>
>>> The Postgress dump from Adam's reply:
>>>
>>>   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 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
>>>
>>> The fromDate was imported correctly. The seed data is not broken. What
>>> is broken is the process used to transfer that data to a server in
>>> another time zone.
>>
>> Your copy of my psql dump is incorrect.  There were 2 rows returned.
>> One was imported on 06-13(the initial import).  Then, on 06-15, the
>> seed xml data was imported a second time, but in a different tz.
> 
> I can guarantee that is what your CDT server contains.
> 
> Anyways, I've done all I can do. I have a job I need to get back to. I
> can reply again on Friday.

Sorta related, but StringToTimestamp converter is broken.  It doesn't
handle timezone parsing.  If the string ends with '.23', it'll change
that to end with '.023'.  However, if it ends with '.23-05', then the
fallback code will not change it to '.023-05'.


> 
> -Adrian

Reply via email to