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.
