Today the clocks went forward in most parts of Australia. And in the UK, clocks went back. I spoke to my grandmother in the UK last night – my grandfather turned 83, but he wasn't well enough to speak.
And I imagine that in both locations, the fact that there was either an hour that didn't happen or an hour that got repeated could potentially have caused issues whenever the time of an event was recorded.
In SQL Server 2008 though, there is a new data type called datetimeoffset. This data type stores the date and time, but also includes time zone. So therefore, if your server is applying daylight saving (and therefore changing time zone), you may have less of an issue now.
Incidentally, the function you should use is no longer getdate(), but now sysdatetimeoffset(). This function, along with sysdatetime() and sysutcdatetime() returns a value which is easily cast into the appropriate data type.