I have started encountering this error today in an Azure SQL environment. There have been no changes to the Azure SQL environment from our end. No changes to schema objects, resources, etc.
I have two databases on the same azure sql server and this error occurs in any cross-database query, but does not happen within a single database.
For example, this query is successful:
select [LAST_MODIFIED], [LAST_MODIFIED] AT TIME ZONE 'UTC' AT TIME ZONE 'AUS Eastern Standard Time'
from hbm_client --this is a local table in the database
And this query fails:
select [LAST_MODIFIED], [LAST_MODIFIED] AT TIME ZONE 'UTC' AT TIME ZONE 'AUS Eastern Standard Time'
from hbm_client --local table
inner join dbo.Account --table in other database, ignore the invalid join, it's not the cause
Any ideas on what could cause this change in behaviour given there were not database changes?
I had the same problem. For some reason AT TIME ZONE works for a lot of my queries but failed for one of them. I haven't done a deep dive of the problem but I found a fix with TRY_CAST
select TRY_CAST([LAST_MODIFIED] AT TIME ZONE 'UTC' AT TIME ZONE 'AUS Eastern Standard Time' AS DATETIME) as [LAST_MODIFIED]
from ...
You can swap out DATETIME for DATE or TIME if you prefer but if the value cannot be cast it will return null instead of an error
Related
I added my schedules in apscheduler(MySQL Database) in UTC time format but now I need to migrate all my schedules to a different time zone like CST or any other time zone inside the database so that they trigger with the modified timezone and not in UTC.
Code snippet:
scheduler_obj.add_job(schedule_request, "cron",id=str(job_obj.request_id),
year="*",month="*",day="*",week="*",day_of_week="*",hour="*", minute="*/5",
second="0", start_date="2018-01-01 03:00:00", end_date="2019-01-01 03:00:00",
misfire_grace_time=15,timezone=ltz)
The Best approach here?
The execution of following SQL in Oracle:
SELECT TZ_OFFSET('Europe/Brussels') from dual;
returns the value +02:00
Note that this function can be used for any timezone in Olsson notation. It's not about the database server.
I was wondering if there exists a similar function in MS Sql Server where you can ask the offset of a given timezone (in the microsoft timezone notation).
From SQL 2016 onward, and in Azure SQL Database, you can achieve this with:
SELECT DATENAME(tz, SYSDATETIMEOFFSET() AT TIME ZONE 'Romance Standard Time')
-- Output: '+02:00'
Notice the time zone names are Windows time zone identifiers, not the IANA TZ (aka Olson) identifiers. For more on the differences, see the timezone tag wiki.
If you want to use IANA TZ identifiers, or if you are using an older version of SQL Server that doesn't have the AT TIME ZONE function, then you can use my SQL Server Time Zone Support project, with the following:
SELECT DATENAME(tz, Tzdb.SwitchZone(SYSDATETIMEOFFSET(), 'Europe/Brussels'))
-- Output: '+02:00'
Also, note that an offset can only be computed for a time zone at a particular reference point. In my examples, you can see I have chosen the current system time with SYSDATETIMEOFFSET(). (The current time is implicit with Oracle's TZ_OFFSET function.)
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
When I run the following query
Viewed.objects.raw('SELECT "recently_viewed_viewed"."id"FROM "recently_viewed_viewed" WHERE NOT ("recently_viewed_viewed"."viewed_date" <= \'timezone.now()\' AND "recently_viewed_viewed"."user_id" = user_id)' )
I get
DataError: invalid input syntax for type timestamp with time zone: "timezone.now()"
I've been struggling with this one haven't been able to figure it out. Any help is always appreciated!
django expect timestamp with time zone But you pass timestamp without time zone. you must add timezone to your time or set USE_TZ = False in your settings.py.
you can use pytz for add timezone . or use this:
timezone.now().replace(tzinfo=timezone.get_default_timezone())
for changing timezone with your setting timezone.
CREATE TABLE DIALOGUE_TABLE(EXPIRE_TIME TIMESTAMP);
Following code snippet is inside stored proc :
PO_EXPIRETIME :- OUT PARAM of procedure a varchar2
SELECT TO_CHAR(SYS_EXTRACT_UTC(EXPIRE_TIME))
INTO PO_EXPIRETIME
FROM DIALOGUE_TABLE;
When I run Stored Proc from server using EXEC and print PO_EXPIRETIME timestamp is proper with UTC format.
But when I call stored procedure from OCCI and client the timestamp recieved is not same but that is the actual timestamp in table not UTC formatted.
Maybe something I am missing but what I don't know?
Is there something in client side I need to do?
If the column is declared as a TIMESTAMP and not, say, a TIMESTAMP WITH TIME ZONE or TIMESTAMP WITH LOCAL TIME ZONE, the timestamp that is stored in the table will not have a time zone component. As a result, SYS_EXTRACT_UTC will convert the timestamp to UTC using the session time zone which is something that is controlled by the client and may be different on different client machines. I suspect that if you run
SELECT SessionTimeZone
FROM dual;
from your OCCI application and from your SQL*Plus session that you will end up with different results which is causing the strings returned to be different.
If you want the string that is returned to be independent of the client machine, I would tend to suggest storing the time zone in the database column. Is changing the schema definition to use a TIMESTAMP WITH TIME ZONE an option? Barring that, you could ensure that every client machine has the same time zone configured and/or run an explicit ALTER SESSION, i.e.
ALTER SESSION
SET time_zone = '-05:00';
in the stored procedure to ensure that the conversion is always done from a particular time zone.