Why does webpages_Membership table CreateDate field have wrong datetime? - sql-server-2012

My IIS 8.0.9200.16384 server (and SQL Server 2012) are set for PST (UTC-8) timezone, yet when using the Microsoft Authentication methods the table Webpages_Membership's CreateDate field shows UTC+8 values.
In our own UserProfile table the datetimes are correct for LastLogin (UTC-8). I can understand that CreateDate was simply UTC, but why is it UTC+8? Does anyone know why this is?

OK, I feel a bit embarrassed, but I found the membership saves datetime.now() as UTC. My server is configured as PST time zone (UTC - 8). Most of my other dateTime fields are recording local time (probably not a good ideal), so that is why the CreateDate field was 8 hours ahead of me. I wasn't the one who programmed the site, so I jumped to the wrong conclusion that there was something wrong.

Related

The datetime columns in all the tables on SQL server have shifted by a few hours

I've created a few tables all of which had a column of datatype datetime. Recently, I think after the daylight savings adjustment, for some reason all the dates have shifted by a few hours i.e. '2022-01-01 00:00:00' has changed to '2021-12-31 18:00:00'.
My guess is that it has something to do with the daylight savings and some server setting related to that but I can't figure out how to revert it back.
Edit:
As suggested in the comments, it might have something to do with the sqoop-export i.e. what I'm using to transfer data from hdfs to sql server. So, the question really is how could I look at what is being inserted into the table. Is there a way I can redirect all insert statements to a log file before being sent over to sql server?

SQL GetDate() returns wrong time

I am having an issue while using GetDate(), for some reason is not returning the right time (it is 7 hours ahead from the actual time) I am using AZURE and the Database is configured with the right location (West US). I will appreciate any help!
I tried to run this script:
SELECT id,
status,
AcceptedDate,
Getdate(),
Datediff(hour, AcceptedDate, Getdate())
FROM orderoffers
WHERE status = 'Accepted'
Azure SQL Databases are always UTC, regardless of the data center. You'll want to handle time zone conversion at your application.
In this scenario, since you want to compare "now" to a data column, make sure AcceptedDate is also stored in UTC.
Reference
The SQL databases on the Azure cloud are pegged against Greenwich Mean Time(GMT) or Coordinated Universal Time(UTC) however many applications are using DateTime.Now which is the time according to the regional settings specified on the host machine.
Sometimes this is not an issue when the DateTime is not used for any time spanning or comparisons and instead for display only. However if you migrate an existing Database to SQL Azure using the dates populated via GETDATE() or DateTime.Now you will have an offset, in your case it’s 7 hours during Daylight Saving Time or 8 hours during Standard Time.
I created a simple function that returns the correct UK time whether in DST or not.
It can be adapted for other time zones where DST kicks in.
CREATE FUNCTION [dbo].[f_CurrentDateTime]() RETURNS DATETIME AS
BEGIN
RETURN DATEADD(HOUR,CONVERT(INT,(SELECT is_currently_dst FROM sys.time_zone_info WHERE 1=1 AND NAME = 'GMT Standard Time')),GETDATE())
END
In this modern times where infrastructure is scaled globally, it is good idea to save data in UTC and convert to a timezone based on users location preference.
Please refere: https://learn.microsoft.com/en-us/dotnet/api/system.datetime.utcnow?view=netframework-4.7.2

SQL may UTC +8 hour issue

........
Where
(microsdb.MENU_ITEM_DETAIL.CheckDetailID = microsdb.CHECK_DETAIL.CheckDetailID Or
microsdb.DISCOUNT_DETAIL.CheckDetailID = microsdb.CHECK_DETAIL.CheckDetailID) And
microsdb.CHECKS.CheckOpen = CONVERT(CHAR(23), CURRENT_TIMESTAMP, 25)
**Return no result.
Field Data Type
microsdb.CHECKS.CheckOpen (datetime, not null)
CheckOpen 2013-04-08 06:29:26.000
I wondered why my CheckOpen time always 8 hours early than my server time.
Please advise.
Thanks
More than likely, when you stored data into the CheckOpen column of your CHECKS table you parsed it (or read it) directly from a client machine or client interface using their time-zone of US/Pacific.
Later, when you read CURRENT_TIME from your DB server you got the system time for that machine in UTC (since the machine was setup to use UTC by your server admin).
So, the two times are 8 hours off. UTC (GMT) is 8 hours ahead of US/Pacific.
Generally, if a client machine gives you data, you need to parse it, validate it, and sometimes translate it to valid server values or be aware when it's stored that it's only a "client" value. For date/time values, either convert to UTC or be sure to store the "offset" with the stored time. (actually it can be good to store offset even after converting to UTC)

SQL Server, strange DATETIME behaviour

I have SQL Server Express 2008 on my local system and I am doing some insertions in a datetime column.
The problem is that the same system on production on (SQL Server 2005) hosted on godaddy records a datetime entry as the previous date and a time of 13:00
E.g. Date being inserted is 07/01/2010 00:00:00
Entry in Local DB = 07/01/2010 00:00:00
Entry in Prod DB = 06/30/2010 13:00:00
Could it be some server/db level setting for datetime storage ?
Edit 1:
pls note, I'm inserting a predefined datetime value, the date being inserted is exactly 07/01/2010 00:00:00. I am NOT using GETDATE().
Edit 2: Solution
Ok, thanks for the answers guys but the problem was not from SQL Server, it was from the data being read from an XML form of the serialized dataset. It was sending the the datetime information as 'mm/dd/yyyy T00:00:00+4:00'
All i did was remove the remove the time segment from it and then insert it in the DB.
Cheers !
You are in Dubai = GMT+y hours
Godaddy is in the USA = GMT-x hours
GETDATE() gives SQL server time
You should use GETUTCDATE() to give GMT (UTC since we lost our empire it appears) which will be consistent globally.
The time difference makes me wonder if this is a UTC thing. Are you running this via SSMS or via application code?
Does it always insert 11 hours behind your local?
Is that an explicit time you're giving the column, or is that the column default (perhaps GETUTCDATE ())?

SQL Server 2005 - Mailqueues use UTC time instead of local time

This is more of a question than a problem as our production system is working as intended.
I am relatively new to the SQL environment. I've been poking through various configurations on the server just to get myself familiarized with the system. One thing that I noticed is the mail queues seem to use the UTC time instead of the local time. For example, if I run
exec sysmail_help_queue_sp
The last empty_rowset_time column shows a time that is exactly 12 hours behind the value getdate() returns (I am in New Zealand) and happens to coincide with the value of getutcdate(). I was more than a little surprised to say the least. The server is configured with the correct time zone (Auckland/Wellington).
I have made sure that the value(s) in the last_empty_rowset_time is indeed updated every time I sp_send_dbmail.
Does anyone know why this is the case? I am just curious to know. I do apologize for my newbiness if this sounds obvious to some of you.
Thanks.
James
This isn't something that is affected by local configuration. Based on documentation here:
http://msdn.microsoft.com/en-us/library/ms187400.aspx
Microsoft explicitly states "military time format and GMT time zone". If you want to see it in your local time zone you'll have to modify your query as such.