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?
Related
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
The TFS server has the time zone set to UTC+1 but if I check the logs of the releases I see that the entries are on a different time zone (UTC-1) resulting in a 2 hours difference.
This is very confusing for the developers because all the other time values (from release summary) are on correct time zone.
How can I change the time zone of the release logs?
Time zone in log is UTC time. And start time is based on the time zone set in TFS server
I am working with CDC in sql and we have a table lsn_timeMapping and a column inside this table trans_begintime its type as mentioned in sql is datetime. My question is how can i get to know that whether it stores datetime in utc format or server datetime .
HERE is a flow mentioned in msdn
It would appear that the time is stored based upon the server's locale settings(local timezone). Therefore, it will not be UTC unless the server timezone is set to UTC.
Source: https://connect.microsoft.com/SQLServer/feedback/details/533689/store-utc-in-lsn-time-mapping
In SQL Server I would like to create a table to save time of an event, and would like to convert it into the timezone of the users choice for display purposes. Let us say that If there was an event that happens in London at 1:00 PM GMT, that would be 8:00 am US EST.
Given This example I would like to create a frame work,
where a user would have an ability to save the event and time (Giving the time zone of the event)
Read Those events, with the time displayed in the time zone of his liking (US EST)
How do I accomplish this in SQL Server.
In SQL Server 2008, use the DATETIMEOFFSET data type which is a DATETIME plus a timezone offset included.
SELECT CAST('2010-11-23 16:35:29+09:00' AS datetimeoffset)
would be Nov 23, 2010, 4:35pm in a +9 hour (from GMT) timezone.
SQL Server 2008 also contains functions and SQL commands to convert DATETIMEOFFSET values from one timezone to another:
SELECT
SWITCHOFFSET(CAST('2010-11-23 16:35:29+09:00' AS datetimeoffset), '+01:00')
would result in:
2010-11-23 08:35:29.0000000 +01:00
Same time, different timezone (+1 hour from GMT)
When you save the data, save the GMT, not the local time for the user (in c# this is DateTime.UtcNow)
In your application logic, record the user's timezone, and translate the GMT time to the user's local time using the timezone offset, at runtime.
The way I've solved a similar problem is to do the following:
The table design is to only store GMT time.
All input goes through a stored proc that requires an input of a timezone offset.
The data request is to a Table-Valued Function, with an input for the timezone offset.
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.