Develop Reference

Create a cron that runs every friday with a specific interval

I want to create a cron that runs in this interval 16/01/2023 - 15/06/2023 every friday at 12 o'clock.
The cron that i created is "0 0 12 ? 1-6 FRI 2023" but i do not know how to put the days interval for january and june.

AFAIK you cannot. Probable 3 schedules:
0 0 12 16-31 1 FRI 2023
0 0 12 ? 2-5 FRI 2023
0 0 12 1-15 6 FRI 2023

How do I get Cron Expression over a specific range of dates?

I want to get valid dates between certain dates via cron expression. Is this possible?
Returns only 1 with getNextValidTimeAfter.
For example, my statement is as follows;
0 0 0? MAY, JUN, JUL MON, TUE 2020-2024
This means:
At 00:00:00 am, on every Monday and Tuesday, in May, June and July, between 2020 and 2024
What I want to do is;
To bring the days in this statement between June 2020 and September 2020.

Months are entered as numbers so it should be something like this: 0 0 0 ? 5-9 * 2020-2024. Look at this resource for more information.

How to run a job from 20.35 until 23.35 every 30 minutes, some days a week?

I am facing a problem with cron expression.
I have to ran a method from Thursday to Sunday by every 30 minutes. It time will start from 20:35 min till 23:35 min.
Cron expression:
"0 35/30 20-23 ? * THU-SUN";
As per my understanding; My method will invoke at 20:35 min at Thursday by every 30 minutes till Sunday.
My Expectation:
Method will invoke as per below timings:
Thu May 19 20:35:00 IST 2016
Thu May 19 21:05:00 IST 2016
Thu May 19 21:40:00 IST 2016
But; Method get invokes by below timings:
Thu May 19 20:35:00 IST 2016
Thu May 19 21:35:00 IST 2016
Thu May 19 22:35:00 IST 2016
Can anyone help me out. Why cron expression evaluating by every 1 hour.??
Here is code example:
#Scheduled(cron="0 35/30 20-23 ? * THU-SUN")
public void startInboundSFTPChannel(){
logger.info("Cron job started....");
downloadSftpFilesController();
}

If you want the command to run from 20.35 to 23.35 every day, from Thursday to Sunday, you can define it in two steps:
35 20 ? * THU-SUN
5-59 21-23 ? * THU-SUN
There is no easy way to set this up in just a cron expression, because you don't want it to run at 20.05.
That is: at 20 , run at the minute 35. At 21 to 23 h, every 30 minutes with an offset of 5 minutes.
I based my answer on this format:
+---------------- minute (0 - 59)
| +------------- hour (0 - 23)
| | +---------- day of month (1 - 31)
| | | +------- month (1 - 12)
| | | | +---- day of week (0 - 6) (Sunday=0 or 7)
| | | | |
* * * * * command to be executed

As I understand, your expression (0 35/30 20-23 ? * THU-SUN) means:
0 - run at full minute only,
35/30 - run every 30 minutes starts from 35,
20-23 - run hours between 20 and 23,
? - use implicit days from later part of expression,
* run at every single month,
THU-SUN - run at Thursday, Friday, Saturday and Sunday.
So, as you specified an increment instead of two values Quartz (which Spring uses) tries to calulate this like the following:
first, it calculates the value 35 for minutes - what matches 0-59 condition,
second, it adds 30 to previous 35 (which equals 65) what not matches 0-59 condition,
at the end, the only correct value is 35.
So, it runs your code every single hour when minutes == 35.
Can you handle running the code one more time at Thu May 19 20:05:00 IST 2016?
If yes, then you can use one of the following expressions:
0 5,35 20-23 ? * THU-SUN
Which means:
0 - run at full minute only,
5,35 - run every 30 minutes, starting from minutes == 5,
20-23 - run hours between 20 and 23,
? - use implicit days from later part of expression,
* - run at every single month,
THU-SUN - run at Thursday, Friday, Saturday and Sunday.
0 5/30 20-23 ? * THU-SUN
Which means:
0 - run at full minute only,
5/30 - run every 30 minutes starting from minutes == 5,
20-23 - run hours between 20 and 23,
? - use implicit days from later part of expression,
* - run at every single month,
THU-SUN - run at Thursday, Friday, Saturday and Sunday.
Here you can find similar problem.

Converting string to milliseconds

I want to calculate the time difference between two dates (in the format "yyyyMMddHHmmss"). The basic idea is to first convert the string date into milliseconds and then get the time difference.
Calendar c1 = Calendar.getInstance();
c1.setTime(new SimpleDateFormat("yyyyMMddHHmmss").parse("20110327032913"));
System.out.println(c1.getTimeInMillis());
Calendar c2 = Calendar.getInstance();
c2.setTime(new SimpleDateFormat("yyyyMMddHHmmss").parse("20110327025913"));
System.out.println(c2.getTimeInMillis());
Result:
1301189353000
1301191153000
Obviously, the first date is later than the second one, but its converted millisecond is smaller. Did I make any error on format?

The time difference between the two timestamps in ms is 30 minutes:
1301191153000 - 1301189353000 = 1800000ms = 30 min
Because of the DST changes on 27 march, the clock is being set forward at 2 AM from 2 AM to 3 AM, hence the timestamps:
20110327032913 => 2011-03-27 03:29:13
20110327025913 => 2011-03-27 02:59:13
are in fact interpreted as:
2011-03-27 03:29:13
2011-03-27 03:59:13 (+1 hour from original time)
Thus, the second timestamp comes later and when converted to ms it is bigger than the first one.

I bet you are in a locale where the time was changed from 2 o'clock (am) to 3 o'clock (am) for daylight saving time on March 27, 2011 (See this link)
Your first time is
2011 03 27 03 29 13
yyyy MM dd HH mm ss
and your second time is
2011 03 27 02 59 13 // does not exist because of time change
yyyy MM dd HH mm ss
so actually, your second time is:
,,
2011 03 27 03 59 13
yyyy MM dd HH mm ss
which is obviously 30 minutes later than your first one (and not 30 minutes earlier).

Perhaps this code can help you:
Calendar c1 = Calendar.getInstance(TimeZone.getTimeZone("UTC"));
Calendar c2 = Calendar.getInstance(TimeZone.getTimeZone("UTC"));
SimpleDateFormat sdf = new SimpleDateFormat("yyyyMMddHHmmss");
sdf.setTimeZone(TimeZone.getTimeZone("UTC"));
c1.setTime(sdf.parse("20110327032913"));
System.out.println(c1.getTimeInMillis());
c2.setTime(sdf.parse("20110327025913"));
System.out.println(c2.getTimeInMillis());
System.out.println((c1.getTimeInMillis()-c2.getTimeInMillis())/(1000*60)+ " minutes");
*The problem is that if your String is not in UTC you may never know if the time change was applied therefore an interval could be one hour off.

wrong result in date difference in android

I want to perform a date operation in my android app. What I want is to subtract two dates and get the result. But subtraction leads to the wrong result whenever I change the time zone to central daylight time.
I use the following code to find the difference between the two dates.
Long lDateDiff = dtCycleDay.getTime() - m_dtHistory[0].getTime();
lDateDiff = lDateDiff / (1000 * 60 * 60 * 24);
Here in m_dtHistory[0], the date stored is Thu Mar 01 00:00:00 CST 2012.
And in my dtCycleDay variable the date changes from Thu Mar 01 00:00:00 CST 2012, Thu Mar 02 00:00:00 CST 2012, Thu Mar 03 00:00:00 CST 2012... and so on.
Now up to Thu Mar 11 00:00:00 CST 2012, the subtraction result is fine, but when the date changes to Thu Mar 12 00:00:00 CDT 2012, the CST changes to CDT and it show wrong subtraction result.
Why this happens and these happen only when I change the time zone to Central Daylight Time or pacific Daylight Time.

What do you mean by the "wrong" subtraction result?
My guess is that the result is 23 hours or 25 hours- which is exactly what I'd expect when a daylight transition occurs, as the intervening day is longer or shorter in terms of elapsed time. The "longer" day won't be relevant when dividing by 24, but the shorter one will... you're assuming that every day has 24 hours, and that you can therefore count the number of days by dividing the elapsed milliseconds by "the number of milliseconds in 24 hours". That doesn't work due to varying day lengths.
Don't forget that a Date value is purely an instant in time. It doesn't know about calendars or time zones... if you want to know the difference in "local" dates and times (where midnight to midnight is always 24 hours), I'd suggest using Joda Time instead... Date and Calendar don't really do that for you.
If the real problem you're describing is the time zone changing at the wrong date, that's a different matter entirely, and could be due to various different causes. For one thing, you should show exactly which time zone you're talking about: the abbreviations are ambiguous, whereas the tzdb names (e.g. "Europe/Paris") aren't.