I want a job a to execute every 15 mins starting from 10:30 AM to 8:30 PM.
I tried 30/15 10-20 * * *. But it ignores the times 11:00 AM, 11:15 AM, 12:00 PM, 12:15 PM, 1:00 PM, 1:15 PM etc.
I would like to know the proper cron string for the above expression.
# Run command every fifteen minutes between 10:30 and 20:30.
0,15,30,45 11-19 * * * …command…
30,45 10 * * * …command…
0,15,30 20 * * * …command…
The first line deals with the whole hours from 11:00 to 19:45. The second line handles 10:30 and 10:45. The third line handles 20:00, 20:15, 20:30 (assuming you want it to run at 20:30 too — if you don't the fix is obvious).
It may not be beautiful, but it will get the job done. Just make sure the …command… sequence is simple enough that the repetition is obvious.
You can probably replace the first component of the first line with 0/15 in your cron. You might use 30/15 for the second one, but it doesn't seem any clearer than what's written anyway. I'm not sure there's a good way to replace the other line.
One other possibility is to refactor it so that the hour range for each quarter hour is specified:
0 11-20 * * * …command…
15 11-20 * * * …command…
30 10-20 * * * …command…
45 10-19 * * * …command…
You could optionally combine the first two of those.
Related
Here comes a head scratcher.
Using the expression:
cast((julianday(arrtime)-julianday(deptime))*24*60 as integer)
to calculate the difference of 2021-05-01 00:19 and 2021-05-01 01:29, gives me 69 minutes?
I can do better than that!
Any idea how to get around?
The problem with the value that you get is that julianday() returns a not exactly accurate floating point number and after the calculations and before casting to an integer, the result is 69.999999850988.
This value, when casting is applied will be truncated to the integer 69.
One solution would be to round the result to an integer instead of casting:
ROUND((julianday(arrtime)-julianday(deptime)) * 24 * 60)
or, since your dates do not contain seconds, use strftime() with '%s' as the format, which returns the number of seconds since 1970-01-01 00:00:00:
(strftime('%s', arrtime) - strftime('%s', deptime)) / 60
See a simplified demo.
If I have everyday datetime - how to find out, the event has already occurred or not, by subtraction with datetime.now()
Let we had everyday meeting at 15:35. Today John came earlier - at 12:45, but Alex was late for 2 h. and 15 min. (came at 17:40).
meet_dt = datetime(year=2015, month=8, day=19, hour=15, minute=35)
john_dt = datetime(year=2015, month=8, day=19, hour=12, minute=45)
alex_dt = datetime(year=2015, month=8, day=19, hour=17, minute=40)
print(meat_dt - john_dt) # came before > 2:50:00
print(meat_dt - alex_dt) # came after > -1 day, 21:55:00
If I take away from the big date less - then everything is fine, but conversely I recive -1 day, 21:55:00 why not -2:15:00, what a minus day?
Because timedeltas are normalized
All of the parts of the timedelta other than the days field are always nonnegative, as described in the documentation.
Incidentally, if you want to see what happened first, don't do this subtraction. Just compare directly with <:
if then < datetime.datetime.now():
# then is in the past
I need to create a cron entry that will kick off a command at both 11:30AM and 4:00PM monday through friday. Is there anyway to do this in one entry or will I need to use two?
This would be great for anyone who has specific times to run their job that don't fall on the same minute of the hours it runs.
Currently I can only figure a two line systems as follows, is this the only way?
# 30 11 * * 1-5 /cmd1
# 00 16 * * 1-5 /cmd1
It is not possible to combine it on just one line.
What you suggest to do:
30 11,16 * * 1-5 /cmd1
would execute even at 16.30.
Then, the only way is splitting in two pieces as you already have:
30 11 * * 1-5 /cmd1
00 16 * * 1-5 /cmd1
You may try this :
30 11,16 * * 1-5 /cmd1
if you accept to change the time of the second command to 16:30.
I am interacting with a Remote Server. This Remote Server is in a different Time Zone. Part of the Authentication requires me to produce the:
"The number of seconds since January 1, 1970 00:00:00 GMT
The server will only accept requests where the timestamp
is within 600s of the current time"
The documentation of erlang:now(). reveals that it can get me the the elapsed time since 00:00 GMT, January 1, 1970 (zero hour)
on the assumption that the underlying OS supports this. It returns a size=3 tuple, {MegaSecs, Secs, MicroSecs}. I tried using element(2,erlang:now()) but the remote server sends me this message:
Timestamp expired: Given timestamp (1970-01-07T14:44:42Z)
not within 600s of server time (2012-01-26T09:51:26Z)
Which of these 3 parameters is the required number of seconds since Jan 1, 1970 ? What aren't i doing right ? Is there something i have to do with the universal time as in calendar:universal_time() ? UPDATEAs an update, i managed to switch off the time-expired problem by using this:
seconds_1970()->
T1 = {{1970,1,1},{0,0,0}},
T2 = calendar:universal_time(),
{Days,{HH,Mins,Secs}} = calendar:time_difference(T1,T2),
(Days * 24 * 60 * 60) + (HH * 60 * 60) + (Mins * 60) + Secs.
However, the question still remains. There must be a way, a fundamental Erlang way of getting this, probably a BIF, right ?
You have to calculate the UNIX time (seconds since 1970) from the results of now(), like this:
{MegaSecs, Secs, MicroSecs} = now().
UnixTime = MegaSecs * 1000000 + Secs.
Just using the second entry of the tuple will tell you the time in seconds since the last decimal trillionellium (in seconds since the UNIX epoch).
[2017 Edit]
now is deprecated, but erlang:timestamp() is not and returns the same format as now did.
Which of these 3 parameters is the required number of seconds since Jan 1, 1970 ?
All three of them, collectively. Look at the given timestamp. It's January 7, 1970. Presumably Secs will be between 0 (inclusive) and 1,000,000 (exclusive). One million seconds is only 11.574 days. You need to use the megaseconds as well as the seconds. Since the error tolerance is 600 seconds you can ignore the microseconds part of the response from erlang:now().
I am writing a program in Fortran and I need a way of calculating the duration of the program down to milliseconds. I have been using the function "date_and_time", which leaves me with an array containing the system's time in hours, minutes, seconds, and milliseconds.
I believe that I can call this function at the start of my program to store the current time, then call the function again at the end of my program to store the latest time. But after that, how would I computer the duration? I tried just subtracting the values, but the milliseconds reset when one second passes, just like the seconds reset when one minute passes. How would be best way to approach this be?
Here is the program:
PROGRAM TEST_TIME_AND_DATE
INTEGER I
REAL J
INTEGER TIME_A(8), TIME_B(8)
CALL DATE_AND_TIME(VALUES=TIME_A)
PRINT '(8I5))', TIME_A
DO I = 0, 400000000
J = I * I - J
END DO
CALL DATE_AND_TIME(VALUES=TIME_B)
print '(8I5))', TIME_B
END PROGRAM TEST_TIME_AND_DATE
And here is the result:
2011 6 11 -300 9 14 49 304
2011 6 11 -300 9 14 50 688
I'm not sure what to do here, thanks.
If you want elapsed clock time, it would be simpler to use the intrinsic procedure system_clock since it provides a single time-value output. (There are additional arguments to provide information about the procedure, which is why it is a procedure instead of a function.) See, for example, http://gcc.gnu.org/onlinedocs/gfortran/SYSTEM_005fCLOCK.html. If you want to time the CPU usage, then use cpu_time. For either, two calls, at the start and end of the program, then a simple difference. You can use the COUNT_RATE argument to convert to integer count of time into seconds.
You can subtract the numbers, then convert everything into milliseconds and sum up the ms, sec in ms, min in ms, hrs in ms, ...
In your case this would be
0 + 0 + 0 + 0 + 0 + 1*1000 + 384 = 1384 [ms]
This approach works fine also with overflows since a positive number in a left-more column outweights negative numbers if they are all converted to the same basis. E.g. 0:58.000 to 1:02.200 yields
1 * 60000 + (-56) * 1000 + 200 = 4200
Please note that this does work up to days but not with months since they do not share a common length.
You could calculate the offset from some starting time (Jan 1, 1970 for UNIX) in seconds or milliseconds. The difference in those numbers is your elapsed time.
(2011 - 1970) * (number of seconds in a year) +
(month of the year - 1) * (number of seconds in a month) +
(day of the month - 1) * (number of seconds in a day) +
( ... )