I have a date 2015-03-11T08:43:19.7810000-05:00 the I am inserting into a MSSQL2008 database table datetime field.
I have verified my SQL Database is currently on daylight savings.
The East Coast of the USA is -5 offset.
Immediately upon inserting into SQL the time changes to 9:43am, adding one hour.
This would tell me some UTC or time zone conversion is not working.
I have even had my DBAs look at this and cannot figure it out.
I believe we should be storing datetime with UTC offset, but cannot figure out why this just started happening after the DST change last weekend.
Thanks.
If you want the offset persisted, you'll need to store it into a datetimeoffset field.
datetime fields do not save the offset. Because you provided one, it is applied but then the time is being normalized to the local time zone, which is in UTC-4 for the date in question.
Related
I want to update a date with a timezone (+2 hours) but it ends up as UTC (0 hours)
Date type is 'timestamp-with-timezone'
Query...
update table set date = '2022-05-25 13:28+02:00'
will end up as this in the database.
2022-05-25 11:28:00+00
What's wrong here?
tl;dr
Nothing wrong. Postgres stores values of TIMESTAMP WITH TIME ZONE in UTC, always an offset from UTC of zero. Any submitted offset or zone is used to adjust to UTC.
Details
Date type is 'timestamp-with-timezone'
No such type in standard SQL, nor in Postgres.
I’ll assume you meant TIMESTAMP WITH TIME ZONE.
it ends up as UTC (0 hours)
Read the fine manual. You are seeing documented behavior.
Postgres always stores values in a column of type TIMESTAMP WITH TIME ZONE in UTC, that is, with an offset of zero hours-minutes-seconds.
Any time zone or offset provided with an input is used to adjust into UTC. That provided zone or offset is then discarded.
So the name of the type TIMESTAMP WITH TIME ZONE is a misnomer. First, the authors of the SQL were thinking in terms of offset, not real time zones. Second, any submitted time zone is not stored. A submitted zone is used to adjust and then discarded.
If you need to track the original offset or zone, add an extra column. You’ll have to add code to store the offset amount or the time zone name.
update table set date = '2022-05-25 13:28+02:00' will end up as this in the database. 2022-05-25 11:28:00+00 What's wrong here?
Nothing is wrong. That is a feature, not a bug. Both of those strings represent the very same simultaneous moment.
FYI, database engines vary widely in their behavior handling date-time types and behaviors.
Some do as Postgres does regarding TIMESTAMP WITH TIME ZONE, adjusting to UTC and then discarding any provided time zone or offset. Some others may not.
The SQL standard barely touches on the topic of date-time handling. It declares a few types, and does that poorly with incomplete coverage of all cases. And the standard neglects to define behavior.
So, be very careful when it comes to date-time handling in your database work. Read very carefully the documentation for your particular database engine. Do not make assumptions. Run experiments to validate your understanding. And know that writing portable SQL code for date-time may not be feasible.
I would like to convert times from pacific to UTC. However, I must first convert the times to either PST or PDT depending on the date. Is there a SQL function that can do this, or does anyone have any advice for creating this function?
The link you provided is pretty much useless as a guide to timestamps. If you are going to work with timezones then store your timestamps in a timestamp with time zone field. The timezone will not actually be stored but the timestamp will be stored as a UTC. Whenever a timestamp is entered it is rotated to a UTC value. This makes working with value easier down the road. If you want to take into account DST transitions you will need to use full timezone names e.g. US/Pacific, as they cover the two offsets(PST/PDT) that constitute the standard/daylight savings timezones. As you found using the offset PST(-08) or PDT(-07) gets you a fixed offset regardless of date.
I’m working with a table that uses date time offset. I have a value that looks like 2020-01-02 13:30:00 -07:00.
Is the time in my time zone 13:30 or do I need to subtract 7 hours from it. I saw people do it differently on YouTube.
In MS SQLServer, the last section of the string representation that you posted of the DateTimeOffset describes the time zone. So, if you are currently located in time zone -7:00 (e.g., Arizona, USA), then the time portion of the string refers to your local time, not UTC. See the Microsoft documentation:
For example, 1999-12-12 12:30:30.12345 -07:00 should be represented [in UTC] as
1999-12-12 19:30:30.12345Z
Someone would subtract the offset from the number only if they want to manually get the UTC value, but that would might produce errors if the data come from a daylight saving time (DST) region, so you would need to enforce DST handling at the time of entry. SQLServer already stores the data in UTC behind the scenes:
The data is stored in the database and processed, compared, sorted,
and indexed in the server as in UTC.
There are two clients with same window application. One is in India and other one is in Belgium. Sql server and web service application is hosted at Belgium. In sql I am storing UTC date time.
Now issue is a time difference for this two clients. I want to show UTC time in history form that mean what is stored in Database I have to bind that data to gird. No any extra code because I suppose to bind UTC date-time. Event then I get time difference for this two client.
Blue header screen is of a Indian client and other one is of a Belgium client. In Belgium time is showing exactly as in Database but difference is for India. Am I missing anything in configuration or what?
You have to convert both time zone in standard UTC and save it. Used dateadd() function to manipulate datetime. such as
declare #IST_date datetime
declare #BE_date datetime
declare #UTC_date datetime
--Indian standard time is (GMT + 5:30 hrs)
-- Belgium standard time is ( GMT + 1 hour)
select #UTC_date = DATEADD(hh,5.30, #IST_date)
select #UTC_date = DATEADD(hh,1, #BE_date)
why not simply convert the value at display ?
DateTime MyDate = Data["ChangedDate"];
DateTime MyDateUTC = MyDate.ToUniversalTime();
tadaaaaa
Ditch System.DateTime and use Noda Time!
Getting Started with Noda Time
System.DateTime uses the system culture and time zone at unpredictable moments, where Noda Time works without any defaults. Takes a bit of work to understand, but you'll never look back.
Use Noda time on the client, and store all the values in UTC in the database. You may also wish to store the original time zone that the date time was entered in.
I would like to convert the date/time values stored in UTC-0 (GMT) to a user preferred time zone value by passing in the time zone (e.g EST, CST etc). However, SQL Server doesn't seem to have a method that takes in a time zone, but does honor the offset. I was wondering if any one had any luck doing so, so that the date/time value reflects the DST change, when a SQL query is issues against the table that contains these values. Oracle is the only database, that seems to honor the Time Zone as well as offset. Please advice.