Data was received from a third party at 6:30 PM GMT.
Automation is scheduled at 8:30 PM (GMT) Dublin, Edinburgh, Lisbon, London
Business unit time zone : (GMT-05:00) Eastern Time (US & Canada)
Query :
SELECT emailaddress,
CAMPAIGN_EXECUTIONDATE
FROM DataExtension
WHERE DATEDIFF(dd,GETDATE(),CAMPAIGN_EXECUTIONDATE)= 0
but it is not getting data from the source DE.
Please suggest what's wrong with the query or something else that I am missing.
Thanks in advance.
I want to run the automation and fetch the data from source data extension and then trigrering the journey via this autimation.
Make sure the data fed to DATEDIFF is of same data type. I guess that's the problem
Related
Problem
My 24 timezone codes are like EAT, ICT, NZT and I need to use the SnowFlake Convert_timezone function to convert the American Eastern time to the timezone that the records have. But SnowFlake Convert_timezone function only supports timezone in standard iana.org time zones format. So what is the best way to map my 24 time zone to the right formate so that the function can work as expected?
I did not figure out how to set up the standard iana.org time zones database and how to convert my time zone code into theirs, please help! thanks in advance!
Sample code
Convert_timezone('American/New_York', my_time_zone_code, my_timestamp) as normalized_time
Error
Unknown timezone: PST
EAT
East Africa Time, or EAT, is a time zone used in eastern Africa. The time zone is three hours ahead of UTC (UTC+03:00), which is the same as Moscow Time, Arabia Standard Time, Further-eastern European Time and Eastern European Summer Time.
Can be safely mapped with snowflake time as below
Africa/Nairobi
ICT
Indochina Time (ICT) is 7 hours ahead of Coordinated Universal Time (UTC).
Iana Timezones where ICT is currently observed.
Can be safely mapped with snowflake time as
Asia/Ho_Chi_Minh
Asia/Bangkok
Asia/Phnom_Penh
Asia/Vientiane
NZT
Most of the time of NZT will be associated with below two zones, to covert it to snowflake standards you have to
divide these zones based on location either one of them
Pacific/Auckland
Pacific/Chatham
Hope this will help
Thanks
Palash
As per Snowflake documentation currently PDT timezone is not supported.
https://docs.snowflake.com/en/sql-reference/parameters.html
However you can follow below link to set system timezone preference.
https://support.snowflake.net/s/question/0D50Z00007MilHISAZ/snowflake-system-timezone-preference
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 posted a similar question here: https://stackoverflow.com/questions/13923598/department-hours-of-operation-for-different-time-zones-in-sql-server
I think I added too much information to the post :)
What I am trying to do is display hours of operations in different time zones. I am having a difficult time figuring out how to display something like Mon - Fri: 630AM to 630PM (UTC -07:00 Arizona) in every other time zone. I'll get to a point (in another time zone) where Monday is no longer Monday...and I can't seem to figure out how to identify the change.
How do I convert a list of days (Monday, Tuesday, etc...) and Times to every other time zone and find the correct day to use?
Time zones are all relative. Australian Eastern Standard Time is UTC+10 and Eastern Daylight Time is UTC+11. USA Eastern Standard Time is UTC-5 and Eastern Daylight Time is UTC-4. To go from 09:00 21 Dec 2012 Australian EDT to US EST is simply DATEADD(h, -16, '09:00 21 Dec 2012'). The only real trick is knowing when Daylight savings in each zone starts and stops and which juristictions it applies in (Daylight Savings is not observed in Queensland for example).
A google search on time zones will give you the info you need to determine where they sit relative to Universal Time (UTC).
The System.Globilization namespace has everything you could need for this. The datetime class has a lot of methods too.
SQL Server Jobs / Schedules - US vs. UK Daylight Savings Adjustment
We have a UK based server which needs to run a SQL Agent Job at 16:30 (US Central time – this may seem strange but it because of the availability of some data). Usually this wouldn’t be a problem because the time difference between the UK and US is 6 hours so we schedule our job for 22:30.
But because the UK and US adjust their clocks at different times in March and November for daylight savings, there is a 2 week period when the time difference between the UK and US is 5 hours.
I would like to implement a way in which SQL Server could identify this change of time difference and then re-schedule the job it’s self using something like sp_update_schedule.
One approach I have is to get the current timestamp on a US based server and then compare that with the current UK time. If the time difference is 5 hours then reschedule the job to 21:30, if the time difference is 6 hours then reschedule the job to 22:30.
But can anyway suggest another solution, perhaps one which wouldn’t involve get the current timestamp on the US based server and ideally not having to store a list of daylight savings adjustment dates in a table. Something more dynamic maybe?
Actually, it looks like you've mentioned the two viable solutions: Ask a server on that timezone or store a list of critical dates. The party line as to why at the first link below. You can implement your own function (which would have to either store a list of dates or ask a server for the offset). Or you can get a public domain list of time zone information (as at the second link below). There are also several web services which will return offsets. Oracle implements that database of time zones to convert between named time zones, so if you already support both you could do that.
There is a C# implementation that you could wrap in CLR functions at the third link.
http://blogs.msdn.com/b/sqlprogrammability/archive/2008/03/18/using-time-zone-data-in-sql-server-2008.aspx
http://www.twinsun.com/tz/tz-link.htm
http://timezone.codeplex.com/
My location in Sydney, Australia. The dates that I explain will be in UK or Australia date format.
Observe the following:
2010-04-15 04:30:00.000 => 15/04/2010 14:30:00 EST (UK date format - Add 10 hours)
2010-11-05 01:00:00.000 => 05/11/2010 12:00:00 EST (UK date format - Add 11 hours)
Both these times are retrieved from the database in UTC format and then calculated on the Web level whether +10 or +11 hour is applicable.
In Australia, Daylight Savings Time (DST) transition dates vary year by year. The transition dates are usually Early April and Late October.
So how accurate would the Web calculation be? If this year the transition date is a few days later (say 03/04/2010), but the Web calculation bases on a fixed date (say 01/04/2010), wouldn't that mean that the days in between will be off by 1 hour when displayed (due to the fixed calculation nature to a specific day of the month)?
I believe the transition dates is not pre-determined and is actually announced to the public. Is that assumption true?
If not (that means the DST dates are pre-determined), would I be able to do the calculation outside the Web level (on the SQL/Database level)?
The database is SQL Server 2005 and I'm using Report Definition Language (RDL) to display the fields in UTC time. If SQL/database level is not the best way, how do I work out +10 or +11 and format the time accordingly to show the right time?
Thank you.
The database is a bad choice for it: it has less information than c# or .net to work it out. .net uses the registry which is kept upto date periodically by patches. SQL Server would have to have a table with date ranges and offsets.
The transitions are fixed because of scheduling (flights, trains ,whatever). IIRC it only changed once at short notice recently in Australia for some Olympic games and it caused chaos around the world. In 2007 the US changed but this was known in advance.
By fixed, it's the "last Sunday" type fixed even if the date varies.
I would leave it in the web code: the DB does not know where your caller is for example, the web site can work it out.
The problem is whoever wrote this app does not quite understand UTC, its value, and how to use it. The database is the correct location for the dat, but the system is not using UTC as intended.
If you use UTC, then all your date arithmetic should use UTC. In the database. It is currently using a saved UTC and then converting at some (doesn't matter if seciond tier or third) other layer; some other library. Half UTC, and Half something else. Have you considered historic dates, as in what is the DATEDIFF() between 15 Feb 2010 and today ?
This eliminates the concern re DST in Australia or Greenland.; and concern re what date/time the changeover actually happens. Everyone is using Greenwich Mean Time for that particular day.
Do all you date arithmetic in the db, in UTC. And display the result (only) in the local time zone, which as you have it, is the web layer, based on the user.
Many systems have dropped that last step altogether, and display in UTC only, regardless of the user's time zone.
The database can handle DST for you. Use its time zone conversion functions to go from whatever zone you stored the dates in to whatever zone you want to get for the user.
MySQL has CONVERT_TZ(), I don't know what other RDBMS's have.