On 6/17/2010 2:29 PM, Adam Heath wrote:
Adrian Crum wrote:
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.
I was going to say:
'2005-01-23 01:23:45.2-05' will be parsed incorrectly as '2005-01-23
01:23:45.002-05'.
'2005-01-23 01:23:45.2' will be parsed correctly as '2005-01-23
01:23:45.200'.
However, I'm noticing some oddities. Issues with postgres 'timestamp'
vs 'timestamp with time zone', java.sql.Timestamp itself not having a
timezone whatsoever. Need to spend more time.
Another thing to watch out for is equating a date-time field type with a
Timestamp. There are no time zone rules defined for date-time fields,
while Timestamps are always referenced to GMT.
