We have created a lookup table and use a case statement to handle Daylight saving. The best solution is to write a UDF and I was hoiping that someone might have created one already but last time I posted the similar question,I did not hear from anyone. I think Netezza should provide this with their SQL add-ons.

In a broader context, some of this is locale-oriented. For example, the UK has daylight savings, but not on the same boundaries as the US. Arizona doesn't do daylight savings at all. Some townships nationwide have opted out of daylight savings. There is a time zone standard in the US of Eastern Standard Time and Eastern Daylight Time etc.

It is also important to keep in mind that no one group is responsible for owning the time-zone lines or standards. These are generally agreed upon but not standardized in the same sense as currency and other regulated domains. Alaska for example is all-inside the international date line not because of geography, but because everyone thinks they should be, and so they are. The IDL is actually drawn-around Alaska on the map.

Many enterprises solve their time zone and time/date issues with a time dimension entity as a one-stop shop, containing all business holidays/bank holidays, designating weekends, quarters, sales and business periods etc. along with the designations for time zones and countries, hourly offsets and the like. This is usually very site/enterprise-specific.

And in case people have been asleep, global enterprises are moving away from nightly processing and are instead using time-zone offsets. This means that when the Hong-Kong markets close, their processes start kicking in while the UK markets are still open, likewise when UK markets close it is 5 hours before the USA markets close, and the UK folks want their data. So the whole idea of a nightly process is washed away in favor of processing "as the world turns" (and all the daytime drama that goes with it)

I agree.  From my experience, though, using a lookup table with the dates and offsets is the best approach  - this can then be incorporated in the ETL and the converted local times can be stored (you can, of course, do the conversions on the fly, but this extra processing (esp if using a BI tool that will generate multi-pass SQL (we were using MSTR)) slowed things quite a bit. 

This project required a conversion of their data (all timestamps were in UTC) to the local time (the client had facilities around the world) - the problem was that each locale had a different offset (of course), and a different date (and even time of day) as to when DST would happen (and this would change from year to year).  Because there were so many variables, having all of the conversions contained within case statements was just too bulky and difficult to manage; instead, I created a lookup table with the DST timestamp associated w/ each locale, then the appropriate hour offset - this would then be added or substracted from the actual data as need to derive the local time.

Since you are only converting to PST, this may be overkill for you; however, I suggest you check the dates and times for prior DST dates (if you have historical data) and future ones so that you don't hard code logic that may incorrect in future years.  If the dates going forward are all over the map, then storing all this in a lookup table may be the cleaner (and more maintainable) approach.

Hope this helps.

This would imply that not only does the time zone need to be data driven, it also needs to be responsive to dynamic changes from bored world leaders, or at least those leaders with too much time on their hands, per the article.

What if Greenwich Mean Time did something really mean?

This just underscores the necessity for it being (meta)data-driven and reasonably dynamic - because there is no clearinghouse or regulatory commission for global time.