For those of you that have not read Simon Sabin's latest blog post you need to be aware of a potential issue with SP1 before you install it.
Pre-SP1, any dates within a SSIS package were interpreted according to the regional settings of the machine on which the package is beng run. So if you have your regional settings set to, say, US English then "01/05/2006" would be interpreted as 5th January 2006. If your regional settings are set to UK English then that would be interpreted as 1st May 2006. [Disclaimer: UK English & UK English are the only formats I am familiar with hence that's what I'm using here.]
Post-SP1 that is no longer the case. "01/05/2006" will always be interpreted as 5th January 2006 regardless of your regional settings. In my opinion this is better behaviour because we can now be confident that dates in a package will always be interpreted the same way regardless of machine settings.
BUT...it could present problems for anyone that uses pre-SP1 packages in a post-SP1 environment. Make sure you retest your packages before going into a production environment with SP1 - particularly if those packages have dates in them.
Kudos to Simon for noticing this.
One last whinge from me. If you open up a .dtsx file in Notepad you will notice that any dates within the package are stored in the format "mm/dd/yyyy hh12:mi:ss PM/AM". As many of you will know this raises the potential problem of ambiguous interpretation. Why oh why have the SSIS development team not encoded dates in the universally accepted unambiguous format of "yyyy-mm-ddThh:mi:ss" - that would have avoided the problems people may experience in moving from pre-SP1 to post-SP1. It seems a bit crazy to me.
If you're interested, read more about unambiguous date formats here: http://blogs.conchango.com/jamiethomson/archive/2005/04/26/1337.aspx.
-Jamie