In Control-M, I have a job that's scheduled 2 minutes after a batch interval ends, e.g. August 13th, 2021 at 00:02 (local time).
I need to pull files from a server on the format "YYDDMMHHMM.zip" and for example "HHMM" could be 2350 (10-minute frequency); the order time for that job would be 23:52.
How do I subtract 2 minutes from the order date/time? And if the system is running in a local time zone, how would one additionally express that result in UTC time? That is, the files on the server are timestamped in UTC time.
The date parameters in Control-M do not include minutes or seconds, %%$DATE will resolve the yyyymmdd value.
If you want yesterday's date (i.e. at 1 minute after New Day Processing you want the previous ODAT value) use the CALCDATE facility to subtract (or add) 'x' days.
If you really want minutes adding/subtracting then that is best done at Unix system level.
Control-M just takes the time/date from the local system time.
You could user "%%CALCDATE %%TIME -120", but it will calculate based on the control-m/server time.
Related
I'm new to autosys.
I wanted to plan a work that starts at 9.00 and runs every 15 minutes. Is this the proper syntax?
start.times=start_times: "09:00"
start_mins:00,15,30,45
You need a run window.
A run window cannot wrap around midnight or whatever time you start your new day processing. The default is midnight
If you want a start time for a job to run every 15 minutes then use this
start_mins: 00,15,30,45
run_window: "09:00-22:00"
22:00 can be whatever you want or as far as 23:59 if your new day processing starts at midnight.
I am quite confused about time concept in airflow. As far as I know, there are at least 5 different time concept in airflow:
UTC time in web UI
Execution time, e.g. start_date, in DAG file
RUN time.
time saved in database
system time
Could anyone explain which are the same and which are different?
The UTC time in the Web UI(1) is the system time (5) being presented.
The run time (3) shows when a task was actually run in UTC and this is the time saved in the database (4) as it corresponds to when a certain task was actually ran in a DAG.
The start_date should be a static non-changing date as it corresponds to when the DAG was first started and should be backfilled if certain parameters like catchup or depends_on_past is set to true.
So 5 and 1 are the same, 3 and 4 are the same, and 5 is it's own entity of time.
As we know, when ever our clocks go 1h back (as they did on 29OCT at 2:00 in some countries) ending the DST period, every timestamp between 1:00 and 2:00 'occurs' twice.
How should an application working with future events handle this?
For example user creates a future event and specifies that it will take a place on 29OCT at 1:35.
And let's assume that standard local time is UTC+3 and the DST is UTC+4
How should the application convert this time to UTC? Should this time be considered as the first instance (before end of DST, which makes it 21:35 UTC) or the second instance (after end of DST, i.e. 22:35 UTC)?
Only you can decide that. It is largely based on context.
In many cases, the right thing to do is to choose the first of the two occurrences - which would be the daylight time. In your example, it would run at 1:35 in UTC+4.
You also need to consider the spring-forward transition. A recurring task that falls into the gap should usually be displaced by an amount equal to the DST bias (which is usually 1 hour). For example, if the clock jumps from 1:59:59.999 to 3:00, then a task scheduled to run at 2:30 would run at 3:30 on that day.
Again, only you can decide what is the right behavior for your application. Some applications may need the fall event to run at the standard time, or at both times. In the spring, they may want to run at the very next instant past the gap (3:00 in the above example, instead of 3:30) - or they may not want to run at all.
See also:
The DST Tag Wiki
How to store repeating dates keeping in mind Daylight Savings Time
Correct way to calculate recurring dates in C#
java Calendar, Date, and Time management for a multi-timezone application
Scheduled Jobs during hours of autumn time change
How can I know if the server where DB2 is running is configured with DST?
CURRENT TIMEZONE special register gives me the difference between UTC and the timestamp, but that difference can change (Summer/winter). Finally, I am not sure in which timezone the server is configured.
Let's suppose Paris is at +1 GMT. In summer, the CURRENT TIMEZONE is 20000, because DST is active, that means 2 hours. In winter, the CURRENT TIMEZONE INDICATES 10000, that corresponds exactly to the +1 GMT.
I would like to retrieve the name of the current timezone, and I could do that by matching the names and values of the timezone (stored in a table or inside a function), with the CURRENT TIMEZONE register and DST.
But how can I get the DST?
https://en.wikipedia.org/wiki/Daylight_saving_time_by_country
https://en.wikipedia.org/wiki/Time_zone
You said:
I would like to retrieve the name of the current timezone, and I could do that by matching the names and values of the timezone (stored in a table or inside a function), with the CURRENT TIMEZONE register and DST.
That is incorrect. Any list that has a time zone offset mapped to a time zone name or identifier is bound to be full of errors, even if it has a flag for if DST is supported or not.
The problem is that many different time zones use the same offset and use DST, but enter and exit DST at different dates and/or different times. Time zones also undergo changes to their rules for what offsets they follow (such as Samoa did in 2011), or for when DST starts and stops (such as the USA did in 2007). And in some cases, DST can be permanently set on or off (such as Russia did in 2011 and is undoing this year).
If you are just wanting to know whether the time zone where your database server is running is in DST or not - you can check the UTC offsets for Jan 1st and Jul 1st. If they are the same, then the time zone doesn't use DST. If they are different, then check the offset for the current time and see which it aligns with. If it's the larger offset, then DST is in effect. If it's the smaller offset then DST is not in effect.
Disclaimer: I am assuming DB2 has a function to get the offset for a particular date. I have not verified that and have little knowledge of DB2 itself.
First off, I'm not a coder by profession, just a lowly network engineer :) But I'm a big believer in automation and try to write scripts to handle tasks they're suited for
I'm attempting to get the current UNIX timestamp for 10 minutes ago in PowerShell, for use in a database-check script. I'm using this to get the current Unix-time:
$unixtime=[int][double]::Parse((Get-Date -UFormat %s))-600
But when I run it through a UNIX-time to local time converter (http://www.onlineconversion.com/unix_time.htm), I'm getting the current time in GMT (for example, if I run it right now I get "1340620608", which the converter says is 10:36 AM GMT, when the actual time is 10:36 AM CDT). This obviously causes issues when comparing to Unix timestamps in the database, as they are in local time. While I could write (or find) a function that would calculate the current GMT offset and apply it to my timestamp, I was wondering if there is a better way to go about this.
Try:
$unixtime=[int][double]::Parse($(Get-Date -date (Get-Date).ToUniversalTime()-uformat %s))
The above gets the current GMT time first then converts it to the correct format.
Does this work for you?
(Get-Date).AddMinutes(-10).Subtract((Get-Date 1/1/1970)).TotalSeconds
Unix timestamps are defined as seconds since 1970-01-01 00:00:00 GMT.
If the timestamps in your database are stored as seconds since 1970 local time, perhaps you need to fix your database. But it's likely that your database timestamps are standard UTC-based Unix timestamps.
You should also check your system's time and timezone settings; your computer may be treating GMT as local time (and its clock could be several hours off).