1. Front end should handle the datetime conversion. Since if we give the conversion to services then it will become more load to the server has services were used by all clients, where most of the clients don't need timezone conversion. 2. By giving the conversion to the front end We need not to do any change in the services and also at the database level. 3. We don't want services to convert datetime as services are handling almost 95% off work there is a lot of room to go wrong. 4. Time zone is a frontend requirement, but not services level requirement. So handling the date conversion at the front end is preferable. 5. By front end handling the datetime conversion, there will not be no effect on services performance. 6. CREATE TABLE dbo.test ( ColDatetimeoffset datetimeoffset ); GO INSERT INTO dbo.test VALUES ('1998-09-20 7:45:50.71345 -5:00'); GO SELECT SWITCHOFFSET (ColDatetimeoffset, '-08:00') FROM dbo.test; GO --Returns: 1998-09-20 04:45:50.7134500 -08:00 SELECT ColDatetimeoffset FROM dbo.test; --Returns: 1998-09-20 07:45:50.7134500 -05:00 7. getdate() This value is derived from the operating system of the computer on which the instance of SQL Server is running. 8.You can change the timezone with tsutil.exe 9. select GETUTCDATE() SQL Server (starting with 2008) Returns a datetime value that contains the date and time of the computer on which the instance of SQL Server is running. The date and time is returned as UTC time (Coordinated Universal Time). 10. Convert from UTC Time to Local Time and automatically taking into account DST (daylight saving time) There is no standard function in T-SQL to convert UTC to local time historically. 11.Luckily enough SQL Server comes with a handy GETUTCDATE() function, which, as you all have guessed, returns the current UTC date. The only thing you need to know to convert your dates to UTC is the offset between your server's time and UTC. You can do it like this: SELECT datediff(hour,GETUTCDATE(), getdate()) SELECT DATEADD(hour, -5, Date)