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
Related
I know there is a system function to get the host name - which returns the Server Name (Application server name in my case).
SELECT HOST_NAME()
Is there a similar function like HOST_TIME() to get the time of application server?
Or is there any workaround at database side to get the time of application server when a procedure is called?
This doesn't sound like a database question to me. You should have the application pass along a timestamp along with whatever query is getting sent along to the database server.
If you must define this at the database level, why don't you simply add the time zone difference? I'm not sure where you're located, though here in the US if I had that issue I would simply do at GETDATE() and then use DATEADD to adjust to the timezone of the other table. The only thing which you would need to spend some time on would be what to do when the time changes (daylight savings time etc.). In my case, none of our users use our system at that hour, though that may be different in your case.
Good luck, and let us know what happens.
I'm using SQL Server 2016 at Amazon AWS. My emails are being sent with incorrect times when sent from my pupper at Amazon. When I try to recreate this bug locally the times are correct. Here is an example of how I use at time zone.
getDate() at time zone 'utc' at time zone u.timezone
where u.timezone is the user's timezone and u refers to an aliased table users.
The times being outputted are at UTC time, so I see 7:36pm instead of 2:36pm (they are formatted with MomentJS)
I don't really know where to start with this one, sorry guys and gals.
UPDATE
My server is sending the correct time (with the correct timezone offset) to the email factory. When the server creates the emails, times are formatted using MomentJS. The barebones moment() function will take a time with a timezone offset (-5:00) and adjust it to the local machine's local time. Local time on my machine is EST, but in Amazon (where the email is being created) is not. Thus I must use moment.parseZone().
From the MomentJS docs:
If your date format has a fixed timezone offset, use moment.parseZone:
moment.parseZone("2013-01-01T00:00:00-13:00");
This results in a date with a fixed offset:
"2013-01-01T00:00:00-13:00"
Since I can't see this change until it is pushed onto our dev environment, I won't be able to know if this fixed it, but I think this was the problem.
My server was sending the correct time (with the correct timezone offset) to the email factory. When the server created the emails, times were formatted using MomentJS.
The barebones moment() function takes a time with a timezone offset (-5:00) and adjusts it to the local machine's local time.
Local time on my machine is EST, but in Amazon (where the email is being created) is not. Thus I must use moment.parseZone().
Changing to moment.parseZone() fixed this issue. Problem solved.
........
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)
When I Use the below code:
Dim cmd As New OdbcCommand("SELECT GETDATE()", oConn)
retVal = cmd.ExecuteScalar()
The resulting output is:
8/1/2013 10:10:39 AM
When I run the exact same query directly in Management Studio I get:
2013-08-01 10:10:39.317
When I check my computer settings versus the SQL Server settings they match.
Anyone know what I need to do to ensure it matches?
Specifically I am talking about the Date format difference.
If you want the date output with a specific string format, then you can use CONVERT() with a style number. For example:
SELECT CONVERT(CHAR(20), GETDATE(), 22),
CONVERT(CHAR(23), GETDATE(), 21);
Results:
-------------------- -----------------------
08/01/13 10:53:54 AM 2013-08-01 10:53:54.943
However, if you are using the date for things other than direct display, only apply that formatting when you are displaying it. For all other purposes it should remain a datetime type and should not be converted to a string.
As for the differences in the actual time value, it's not clear what problem you're talking about, but I suspect you simply ran these queries half an hour apart. If those were run at or around the same time, it looks like the server is half an hour fast - maybe it's in a different time zone or maybe it's just a lot of drift or someone not bothering to use a time service. Your application should never use the time / time zone of the client, especially if it's distributed - always use the time on the server.
Dates have no format. Format comes into play only when you convert dates to a string. The forma used depends on who does the conversion: the server or the client?
Your VB.NET query returns a date from the server and converts it to a string when you write it to the console, a form or whatever. VB.NET uses your programm's CurrentCulture, whose defaults come from the current user's regional settings.
When you display data in SSMS, an ISO format is used so there is no ambiguity when you edit the data.
When you compare date and string values in a query, either explicitly by converting a date to a string or implicitly because you just typed MyDate = '13/1/2013, a conversion is made using the column's collation. Collations are inheritted so the column's collation is the same as the database's collation.
Try this:
net time \\SERVER_NAME
Note: Obviously SERVER_NAME is the name of your SQL Server machine.
Do you see a 30 minute difference in the result of that call?
I looked deeper into the code and found that some enterprising fellow had added code to a line of SQL later in the process which forces DMY format on that query.
so the code in the VB is returning the proper Date on the app machine. Which means that there must be a difference between my computer and the app machine.
Another coder ran into the same issue and so there solution was to add the below code to the SQL that was pulling from the DB.
SET DATEFORMAT dmy
This forces the SQL to use DMY format... I removed this code Compiled and ran the EXE from the server machine and my issue dried up!
Thanks for everyone's help.
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 ())?