SQL DateTimes stored in UTC get beginning of day based on offset - sql

This may be the most pathetic question ever asked related to SQL and date/time values, but I could use some help...
Trying to setup a function/job that will run at a specified time or times in eastern, mountain, central, and pacific time zones (in theory other zones would work too). The system will identify which users belong to each timezone and then output data from the system highlighting what they've accomplished for the current day.
Here is my challenge, I know all date/time values are stored on the SQL DB in UTC. I can apply the offset and convert those times to local time zones. Rather than convert tens of thousands of date/time values to local time and make comparisons there, it'd be cleaner (I think) to simply adjust the beginning and ending date/time values of UTC within the stored procedure.
On the west coast it is currently just about 2017-09-30 14:30:00 and in UTC is 2017-09-30 21:30:00, this clearly demonstrates a 7 hour time zone difference right now which means "today" from a user perspective technically started at 2017-09-30 07:00:00 and will end on 2017-10-01 06:59:999 in UTC.
What is the best way of establishing these date/time values for a users beginning of day and ending of day values?
UPDATES
I currently have this code...
DECLARE #InputDate as DateTime
DECLARE #InputEndDate as DateTime
DECLARE #InputDateWithOffset as DateTimeOffSet
DECLARE #InputEndDateWithOffset as DateTimeOffSet
SET #InputDate = '2017-09-28'
SET #InputDateWithOffset = #InputDate AT TIME ZONE 'UTC' AT TIME ZONE 'Pacific Standard Time'
SET #InputEndDate = DATEADD(day, 1, DATEADD(ms, -3, #InputDate))
SET #InputEndDateWithOffset = #InputEndDate AT TIME ZONE 'UTC' AT TIME ZONE 'Pacific Standard Time'
SELECT
#InputDate AS InputDate, #InputEndDate AS InputEndDate,
#InputDateWithOffset AS InputDateWithOffset,
#InputEndDateWithOffset AS InputEndDateWithOffset
Which outputs the following:
The last two columns appear to be correct as it would represent both the beginning of the Input Date and the ending of the Input Date as the Input Date is going to be the local date of the execution...
When I take the #InputDateWithOffset and #InputEndDateWithOffset against my table values with datetimes in UTC, it appears the only dates being returned are those that fall on 2017-09-28 and seems to disregard the comparisons to the Offset date/times.

Your update is mostly correct. However, you're missing a "start of day" operation, which needs to be done in local time.
Consider:
DECLARE #InputStartUTC as DATETIME, #InputEndUTC as DATETIME
DECLARE #InputStartDTO as DATETIMEOFFSET, #InputEndDTO as DATETIMEOFFSET
DECLARE #InputStartDTOatStartOfDay as DATETIMEOFFSET,
#InputEndDTOatStartOfDay as DATETIMEOFFSET
DECLARE #tz as VARCHAR(50) = 'Pacific Standard Time'
SET #InputStartUTC = '2017-09-28 00:00:00'
SET #InputStartDTO = #InputStartUTC AT TIME ZONE 'UTC' AT TIME ZONE #tz
SET #InputStartDTOatStartOfDay = CAST(CAST(#InputStartDTO as DATE) as DATETIME)
AT TIME ZONE #tz
SET #InputEndUTC = DATEADD(day, 1, #InputStartUTC)
SET #InputEndDTO = #InputEndUTC AT TIME ZONE 'UTC' AT TIME ZONE #tz
SET #InputEndDTOatStartOfDay = CAST(CAST(#InputEndDTO as DATE) as DATETIME)
AT TIME ZONE #tz
SELECT
#InputStartUTC as InputStartUTC, #InputEndUTC as InputEndUTC,
#InputStartDTO as InputStartDTO, #InputEndDTO as InputEndDTO,
#InputStartDTOatStartOfDay as InputStartDTOatStartOfDay,
#InputEndDTOatStartOfDay as InputEndDTOatStartOfDay
Also, notice I did not subtract three milliseconds from your end date. Rather than trying to figure out .997 or .999 or whatever, the better approach is to query using a half-open interval. In other words, start <= value AND end > value.

Related

Add offset value to time in SQL Server

I felt like this should be easy but I'm not finding answer. The query below will give me the current date/time in California and represent it as UTC with a timezone offset (currently -08:00):
select getdate() at time zone 'Pacific Standard Time'
I simply want to apply the offset and get a timestamp showing the current local time and then drop the offset. I feel like there should be a way to achieve this without having to pick through it with string and date functions. For example, I want to go from
2021-11-24 18:03:41.190 -08:00
to
2021-11-24 10:03:41.190
Is there a succinct way to do this?
When you use AT TIME ZONE on a value that isn't a datetimeoffset it's assumed that the value is at the time zone you are converting it to.
Instead, therefore, you could nest the AT TIME ZONE clauses. If you did do this though, I would also suggest using SYSUTCDATE rather than GETDATE (which returns the local time to the host, which could be any timezone).
SELECT SYSUTCDATETIME() AT TIME ZONE 'UTC' AT TIME ZONE 'Pacific Standard Time';
Though really, just use SYSDATETIMEOFFSET to start with; then you just need one AT TIME ZONE as the RDBMS already knows what timezone the value is for.
SELECT SYSDATETIMEOFFSET() AT TIME ZONE 'Pacific Standard Time';
db<>fiddle
Declare #myDateTime datetime = '2021-11-24 21:35:25.984'; --UTC time
Select cast(#myDateTime At Time Zone 'UTC' At Time Zone 'Pacific Standard Time' As datetime);
Or - you can just apply the desired offset and convert back to datetime
Select cast(switchoffset(#myDateTime, '-08:00') As datetime)
The problem with using switchoffset is that it isn't DST aware and would need to be changed to use a different offset value. If you change the date above to October - the PST time would be 14:35:25.983 but the second calculation still returns 13:35:25.983

Day light savings time is resulting in incorrect dates in database

BACKGROUND:
I have an issue with the day light savings time change. Any records entered into the database (side note: I have no access to the script/code which enters this data to fix it) between 2021-03-28 and 2021-10-31 get entered into the database with the incorrect date. For example:
Records entered in on 2021-03-26 end up in the database as 2021-03-26 00:00:00, which is correct.
Records entered in on 2021-03-29 end up in the database as 2021-03-28 23:00:00 which is incorrect.
So when I try to search for records entered in on2021-03-26, the query works fine, but if I try to search for records entered in on 2021-03-29, it returns records from the wrong date because of the hour change.
SAMPLE DATA:
ColDate, ColName
2021-03-26 00:00:00, SomeName -- CORRECT DATE
2021-03-26 00:00:00, SomeName -- CORRECT DATE
2021-03-26 00:00:00, SomeName -- CORRECT DATE
2021-03-28 23:00:00, SomeName -- INCORRECT DATE
2021-03-28 23:00:00, SomeName -- INCORRECT DATE
2021-03-28 23:00:00, SomeName -- INCORRECT DATE
WORKING EXAMPLE:
DECLARE #StartDate datetime
DECLARE #EndDate datetime
SET #StartDate = '2021-03-26 00:00:00'
SET #EndDate = '2021-03-26 23:59:59'
SELECT *
FROM tblName
WHERE ColDate BETWEEN #StartDate AND #EndDate
The above will return:
ColDate, ColName
2021-03-26 00:00:00, SomeName -- CORRECT DATE
2021-03-26 00:00:00, SomeName -- CORRECT DATE
2021-03-26 00:00:00, SomeName -- CORRECT DATE
NONE WORKING EXAMPLE:
DECLARE #StartDate datetime
DECLARE #EndDate datetime
SET #StartDate = '2021-03-29 00:00:00'
SET #EndDate = '2021-03-29 23:59:59'
SELECT *
FROM tblName
WHERE ColDate BETWEEN #StartDate AND #EndDate
The above will return nothing from the sample data.
QUESTION:
How do I get around this issue? As mentioned earlier, I have no control of the data entry and the developers have no interest in fixing the issue.
Do I need to use IF statements and check if the date is between 2021-03-28 and 2021-10-31 and adjust the date by 1 hour accordingly? Or is there a better way to resolve this?
UPDATE - POSSIBLE SOLUTION:
The following query seems to work (2021-03-26):
DECLARE #StartDate datetime
DECLARE #EndDate datetime
SET #StartDate = '2021-03-26 00:00:00'
SET #EndDate = '2021-03-26 23:59:59'
SELECT
ColDate AT TIME ZONE 'UTC' AT TIME ZONE 'GMT Standard Time',
ColName
FROM tblName
WHERE ColDate BETWEEN #StartDate AT TIME ZONE 'GMT Standard Time' AT TIME ZONE 'UTC' AND #EndDate AT TIME ZONE 'GMT Standard Time' AT TIME ZONE 'UTC'
The following query seems to work (2021-03-29):
DECLARE #StartDate datetime
DECLARE #EndDate datetime
SET #StartDate = '2021-03-29 00:00:00'
SET #EndDate = '2021-03-29 23:59:59'
SELECT
ColDate AT TIME ZONE 'UTC' AT TIME ZONE 'GMT Standard Time',
ColName
FROM tblName
WHERE ColDate BETWEEN #StartDate AT TIME ZONE 'GMT Standard Time' AT TIME ZONE 'UTC' AND #EndDate AT TIME ZONE 'GMT Standard Time' AT TIME ZONE 'UTC'
UPDATE - QUESTION:
The above update seems to work, but am I overlooking anything?
Your updated answer seems great. But if the correct entered date is always without time and only incorrect ones are entered with time part then you can also just subtract 1 hour from #startdate while using it in where clause.
DECLARE #StartDate datetime
DECLARE #EndDate datetime
SET #StartDate = '2021-03-29 00:00:00'
SET #EndDate = '2021-03-29 23:59:59'
SELECT *
FROM tblName
WHERE ColDate BETWEEN dateadd(day,-1,#StartDate) AND #EndDate
But it won't work if there are rows with time part other than day light saving issue.
if I am overlooking anything
You might.
You should try to understand how exactly the data entry app works. You can't change it, but you should be able to reverse engineer the code. Once you understand how the code transforms the timestamps, you may try to come up with the reversing transformation.
In your proposed solution you convert timestamp to a GMT Standard Time time zone. You should verify if your data entry app operates with this time zone. Different time zones switch between day light savings on different dates. It is not like the whole world moves their clock on the same day of the year. Some time zones don't have a day light saving at all.
Also, rules for time zones tend to change over time. Governments like to make changes. So, if your database spans across lengthy period you may discover that the rules for the time zones that are built into SQL Server now are not the same that were in place when the data was recorded. For example, Perth in Western Australia moved their clocks in 1991-1992, then again in 2006-2009, then stopped doing it. At least, DST is not observed now.
So, things to consider:
what time zone to use?
does all of your data fall into the same time zone? If the data comes from several different time zones, their rules may be different and you need to know which transformation to apply to which parts of the data.
does your data span across the period when the rules for your chosen time zone changed?
So, in general case it becomes pretty hard to fix the timestamps after the fact.
You can't change your app now, but a note for the future.
In my system I make sure to store both local and UTC time. When an entry is generated by a local computer, it usually knows its local time zone and UTC time accurately. When I have a central database with timestamps from various locations I do not attempt to convert local->UTC or UTC->local. I use appropriate field. Some reports use local times, some reports use UTC.
Daylight (DST) time is actually an offset comparing with Local time. The majority of SQL databases has UTC internal conversion when using datetime in column type.
A very nice practice to resolve your issue is to convert your datetime string to milliseconds!!!
var myDate1 = Date.parse("2021-03-26 00:00:00")
//1616709600000
var myDate2 = Date.parse("2021-03-28 00:00:00")
//1616882400000
TIP: calculate here the time zone offset programmatic and convert it to milliseconds, now you can add it to MyDate1, MyDate2 before run your Query
var time_zone_correction = today.getTimezoneOffset()*60*1000;
When you are ready call your query with the following syntax:
DECLARE #UTC1 BIGINT
DECLARE #UTC2 BIGINT
SET #UTC1 = '"+myDate1+"'
SET #UTC2 = '"+myDate2+"'
SELECT * FROM yourTableHere WHERE [DATE]
BETWEEN DATEADD(SECOND, #UTC1/1000, '19700101')AND DATEADD(SECOND, #UTC2/1000, '19700101') order by [DATE]"
Moreover you can check your SQL for registered timeZones by running this select * from sys.time_zone_info
Note: Milliseconds has precision over Date() object conversion from strings, also the execution time of a BIGINT compared to string datetime conversion is much faster.
In terms of code re-usability, if you add your offset (milliseconds calculation) for time zones before executing your query and not inside, you end up with a dynamic and more "template" approach of writing a query.
Give it a try and research the web, there are tons of tutorials for dealing with UTC, DST and timezone manipulation!
I hope my approach will help you!
I think you need 2 time funcs (see bellow)
dbo.fnToDbTime for Filter times
dbo.fnToYourTime for format Result time
DECLARE #StartDate datetime = '2021-03-28'
DECLARE #EndDate datetime = #StartDate + 1
SET #StartDate = dbo.fnToDbTime(#StartDate)
SET #EndDate = dbo.fnToDbTime(#EndDate)
SELECT [ColDate], [ColName], dbo.fnToYourTime([ColDate]) GoodTime
FROM tblName
WHERE #StartDate <= ColDate AND ColDate < #EndDate
GO
CREATE FUNCTION dbo.fnToDbTime (#YourTime datetime)
RETURNS datetime
AS
BEGIN
DECLARE #DbTime datetime
IF #YourTime < '2021-03-29 00:00:00'
SET #DbTime = #YourTime
ELSE IF #YourTime < '2021-10-31 00:00:00'
SET #DbTime = DATEADD(HH, -1, #YourTime)
RETURN #DbTime
END
GO
CREATE FUNCTION dbo.fnToYourTime (#DbTime datetime)
RETURNS datetime
AS
BEGIN
DECLARE #YourTime datetime
IF #DbTime < '2021-03-28 23:00:00'
SET #YourTime = #DbTime
ELSE IF #DbTime < '2021-10-30 23:00:00'
SET #YourTime = DATEADD(HH, 1, #DbTime)
RETURN #YourTime
END
GO

Proper way of getting rows since a date accounting for DST?

I have a datetime column, changedate, that I need to use to get rows that have changed in the last week since 1PM. This column is unfortunately in local time (EST). The server is Microsoft SQL Server 2016.
Here is the query I have now:
DECLARE #since datetime = DATEADD(week,-1,SMALLDATETIMEFROMPARTS(YEAR(GETDATE()), MONTH(GETDATE()), DAY(GETDATE()), 13, 0)) AT TIME ZONE 'Eastern Standard Time'
SELECT * FROM table WHERE changedate AT TIME ZONE 'Eastern Standard Time' >= #since
Since I'm using AT TIME ZONE for both the column and #since, will this properly account for DST changes? That's my understanding per the documentation I've found, but I'm not 100% sure if that's how it works or if I'm missing something.
First, figure out the time you're wanting to compare against:
-- Get the current date in the given time zone
DECLARE #today date = convert(date, sysdatetimeoffset() AT TIME ZONE 'Eastern Standard Time')
-- Get the date one week ago
DECLARE #dateOneWeekAgo date = DATEADD(week, -1, #today)
-- Join the date with the desired time (local to the same time zone)
DECLARE #since datetime = convert(datetime, #dateOneWeekAgo) + convert(datetime, timefromparts(1, 0, 0, 0, 0))
Then just compare it:
SELECT * FROM table WHERE changedate >= #since
That assumes your changedate field is a datetime or datetime2. If it's a datetimeoffset, you should first convert the target value to a datetimeoffset in the same time zone and use that instead:
DECLARE #sinceDTO datetimeoffset = #since AT TIME ZONE 'Eastern Standard Time'
Regarding the approach you gave in the question, there two issues:
getdate() gives the time based on the server's local time zone. It's possible that it's not the same day in Eastern Time.
You should never apply a function (whether an intrinsic like AT TIME ZONE or something else) against a table field in a where clause, because it makes the query non-sargable. In other words, SQL would have to scan the entire table, rather than using an index. The bigger the table, the slower the query would take.

Compare datetimeoffset with timezone SQL

I have a date emp_date which is of type datetime offset. This date is saved correctly in the database.
I want to retrieve all data having the date emp_date less than the actual time, including time zone.
For example, if the emp_date is as below:
2019-10-25 23:44:09.5798885 +14:00
And I am in a time zone of +2, then the data having the above date should not be retrieved.
Any idea of how to do this?
I want to pass the timezone of the user as parameter.
https://dzone.com/articles/dates-and-times-in-sql-server-at-time-zone
pass the needed time zone as parameter, then we can convert to the needed time zone.
DECLARE #TimeZone varchar(50)
SET #TimeZone = 'Central European Standard Time'
SELECT getdate() AT TIME ZONE #TimeZone AS date
SELECT getdate() AT TIME ZONE 'Central European Standard Time' AS date

Get a specific date in a specific time zone

I am trying to derive a given date from a DB that is in Greenwich Mean Time. so I need to constantly account for the discrepancy.
DECLARE #date datetime
DECLARE #tempdate datetime = '3/1/2019'
SET #date = #tempdate AT TIME ZONE 'UTC' AT TIME ZONE 'Central Standard
Time'
SELECT #date
The above code produces a date several hours before March 1st (since I am in the U.S.). Is there a generic way to always grab Central Time for any desired date?
IF you are trying to convert UTC time into US Central Time it is indeed normal to receive a Central time that is earlier that UTC time. Sun rises in Greenwich first and sometime later rises in Chicago, so the March begins first in UTC zone, few hours prior to doing it in Chicago. Same goes for other months! :)