| Author |
Topic |
|
Michael Valentine Jones
Yak DBA Kernel (pronounced Colonel)
7020 Posts |
Posted - 2005-06-12 : 14:28:16
|
Does any one know of functions, extended stored procedures, or any other method of converting a time in a particular time zone to UTC (Coordinated Universal Time). I would like to be able to convert times to and from UTC time to local time for events that happen at offices throughout the world.The GETUTCDATE() function will not do the job, because the SQL Server is not usually located in the same location as the office where the transaction is taking place. It would have to handle the changes of relative time to UTC when the local spot switches from daylight savings time to standard time, and it would have to handle all of the world’s time zones.Anyone know of a way to do this in SQL Server? Is there a commercial SQL Server add-on product that might do this?Something along the line of:Declare @local_date datetimeDeclare @utc_date datetimeDeclare @timezone_id intSelect @local_date = '2007/7/17 18:43:22.118'Select @timezone_id = 7Select @utc_date = dbo.F_LOCAL_TO_UTC_DATETIME( @local_date, @timezone_id ) Select @local_date = dbo.F_UTC_TO_LOCAL_DATETIME( @utc_date, @timezone_id ) CODO ERGO SUM |
|
|
spirit1
Cybernetic Yak Master
11752 Posts |
|
|
TG
Master Smack Fu Yak Hacker
6065 Posts |
Posted - 2005-06-13 : 11:42:10
|
| I used to use swatch time, but my friends teased me for wearing a big pink watch band :DMichael, one thought: If you use .net framework with soap serialization, datetimes are automagically adjusted for timezones during serialization/deserialization.Be One with the OptimizerTG |
 |
|
|
TG
Master Smack Fu Yak Hacker
6065 Posts |
Posted - 2005-06-13 : 11:48:02
|
Another thought. Maybe you could send the offset along with your datetime values:select timeZoneOffset = datediff(hour, getdate(), getutcdate()) ,myDateTime = @myDateTime then make the adjustment at the server.Be One with the OptimizerTG |
 |
|
|
Michael Valentine Jones
Yak DBA Kernel (pronounced Colonel)
7020 Posts |
Posted - 2005-06-13 : 12:11:05
|
| The problem that I have is that the data is coming from many sources, and it is not always a Microsoft platform, or a web application. Actually the problem would be trivial if I knew the offset to UTC, but that is the real problem. For example, someone calls your service number, and leaves a message to call them on a certain number at 10:00 am their time. You have to know what time zone they are in, and you have to know the daylight savings time rules for that time zone. This is a lot trickier than it sounds. Within the US, some states are split across time zones. Arizona does not observe the same daylight savings time rule across the entire state, even though the entire state is in the same time zone; the Indian reservations in Arizona observe daylight savings time, and the rest of the state doesn’t.Also, I may be receiving data files with dates from last week or month, so I have to be able to determine the UTC offset that was in effect at that time.Basically, the world can be divided into geographic areas such that within each area, the rules for UTC offset are always the same. I am looking for something that knows all those areas, and given a date time and time zone area identifier can give the offset to/from UTC.CODO ERGO SUM |
 |
|
|
ajthepoolman
Constraint Violating Yak Guru
384 Posts |
Posted - 2005-06-13 : 12:17:53
|
| Be like the cable company and tell them that you will return their call between 9AM and 5PM. On a practical note, it seems that you would have to maintain some sort of "benchmark" time zone. Pick your favorite one and then break regions down into timezones and do your best from that point. With your benchmark you can at least calculate times relatively accurately, with the exception of areas that don't observe daylight savings and such. Aj |
 |
|
|
TG
Master Smack Fu Yak Hacker
6065 Posts |
Posted - 2005-06-13 : 12:58:32
|
hmmm...well you being the super kernal kernel dba that you are I don't think I come up with anything that you haven't already thought of. But to just think outloud for a second:I guess there is 2 possible directions. Either each datasource needs to know their own utc offset, or your db server needs to know from which datasource all data originates. If the latter can be true I guess you could create a new datasource table with an SP that knows the rules for figuring the offset for each datasource.But I guess your original question was "does a source of geographic regions and their utc offsets exist?" Sorry, I don't know of one.Be One with the OptimizerTG |
 |
|
|
Michael Valentine Jones
Yak DBA Kernel (pronounced Colonel)
7020 Posts |
Posted - 2005-06-13 : 14:07:00
|
| What I was thinking it that there might be is a system API that could handle the time zone conversions. When you pick a time zone on Windows system setup, it has a fairly complete list of at least US time zones, and it handles conversions of files timestamps and email created in different time zones. This really isn't the forum to ask about system APIs though.I guess my original fantasy of a freeware or commercial extended stored procedure that does this is not going to come true.CODO ERGO SUM |
 |
|
|
spirit1
Cybernetic Yak Master
11752 Posts |
|
|
Lumbago
Norsk Yak Master
3271 Posts |
Posted - 2005-06-14 : 13:28:59
|
I might be totally off here but isn't it possible for you to send the current timestamp from the client to the server? By doing that you would be able to do a DATEDIFF between the clients timestamp and GETDATE() from the server and it would give you the offset in hours. Having that you would be able to tell what timezone the client is in relative to the server and you could just add the offset...here's an example:DECLARE @DueDateTime datetime, @Clienttime datetime, @Servertime datetimeSET @DueDateTime = '2005-07-01 12:00:00'SET @Clienttime = '2005-06-14 15:00:00'SET @Servertime = '2005-06-14 18:00:00'SELECT DATEADD(hh, DATEDIFF(hh, @Clienttime, @Servertime), @DueDateTime) Hm...when writing this it almost seems to simple to solve your problem, but from what I can understand from the description of your problem it could be useful (given that it doesn't take an hour to get the data from the client to the server and that daylight savings time changes on the same days throughout the different places). Hm. let's hope I'm not making a fool of myself --Lumbago"Real programmers don't document, if it was hard to write it should be hard to understand" |
 |
|
|
Michael Valentine Jones
Yak DBA Kernel (pronounced Colonel)
7020 Posts |
Posted - 2005-06-14 : 13:46:28
|
There are a couple of reason I can't do this that I described before:1. I may be receiving data files with dates from last week or month, so I have to be able to determine the UTC offset that was in effect at that time, not just what is is now.2. The times I am interested in may not be the times from a server, but from user input like this: Someone calls your service number, and leaves a message to call them on a certain number at 10:00 am their time. You have to know what time zone they are in, and you have to know the daylight savings time rules for that time zone. There are comercially available tables available that will give geographic infomation for a given area code and prefix, but that doesn't give you the UTC offset in effect at that time.quote: Originally posted by Lumbago I might be totally off here but isn't it possible for you to send the current timestamp from the client to the server? By doing that you would be able to do a DATEDIFF between the clients timestamp and GETDATE() from the server and it would give you the offset in hours. Having that you would be able to tell what timezone the client is in relative to the server and you could just add the offset...here's an example:DECLARE @DueDateTime datetime, @Clienttime datetime, @Servertime datetimeSET @DueDateTime = '2005-07-01 12:00:00'SET @Clienttime = '2005-06-14 15:00:00'SET @Servertime = '2005-06-14 18:00:00'SELECT DATEADD(hh, DATEDIFF(hh, @Clienttime, @Servertime), @DueDateTime) Hm...when writing this it almost seems to simple to solve your problem, but from what I can understand from the description of your problem it could be useful (given that it doesn't take an hour to get the data from the client to the server and that daylight savings time changes on the same days throughout the different places). Hm. let's hope I'm not making a fool of myself --Lumbago"Real programmers don't document, if it was hard to write it should be hard to understand"
CODO ERGO SUM |
 |
|
|
|