On 6/17/2010 2:07 PM, Adam Heath wrote:
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'.
What is timezone parsing? I agree it doesn't mimic the Timestamp.valueOf
method, but that is intentional to maintain backward compatibility.
