4

I need to know whether the period defined by:

DateTime start;
DateTime end;

has a DST inside.

I am iterating over collection of periods defined by {start,end} and shifting start and end 24 hours forward in every iteration. The resulting period starts at midnight and ends at 1 ms before next midnight. I found that if the period has a daylight saving point inside the shift produces incorrect result, e.g:

having:

Duration targetDuration = new Duration(24*60*60*1000L-1);
DateTime start = new DateTime("2012-03-10T00:00:00.000-08:00");
DateTime end = new DateTime("2012-03-10T23:59:59.999-08:00");

then the shift is done: 

start = end.plusMillis(1);
end = start.plus(targetDuration);

produces:

start = "2012-03-11T00:00:00.000-08:00"
end = "2012-03-12T00:59:59.999-07:00"

I wonder is there any standard API in JodaTime that can check whether the period of time has a DST inside?

aviad
  • 8,229
  • 9
  • 50
  • 98
  • See: http://stackoverflow.com/a/154765/44522 – MicSim Jul 09 '12 at 06:21
  • @MicSim, thanks but the question was about JodaTime standard API. I am looking for one-liner not for the long arithmetics on unix time. – aviad Jul 09 '12 at 06:24

3 Answers3

4

Use the DateTimeZone.nextTransition method. If the start is less than the end DateTime, then at least one time zone transition has occurred in between. This does not account for rule changes vs. DST. That is, a time zone might have a new rule indicating that standard time has a new offset, and this would appear as a time zone transition.

if (start.getZone().nextTransition(start.getMillis()) < end.getMillis()) {
    // Time zone transition occurred, possibly due to DST
    ...
}
boneill
  • 1,478
  • 1
  • 11
  • 18
2

As long as start and end are in the correct time zone (e.g., created using this constructor) then the Interval created using them should take DST for that time zone into account. If the Duration of that Interval is not equal to 24 hours, then you've crossed the DST point.

Edward Samson
  • 2,395
  • 2
  • 26
  • 39
  • This is not a good general purpose solution for arbitrary dates. If there are multiple DST transitions, then the duration can still end up being evenly divisible by 24. – boneill Jul 11 '12 at 04:12
  • I don't see how there can be multiple DST transitions within a single 24-hour period, as was asked. Nonetheless, yours is indeed better for arbitrary dates. – Edward Samson Jul 13 '12 at 05:41
0

Because Daylight Savings Time is heavily reliant on TimeZones (some areas don't practice DST, some move clocks 1 hour, some 2 etc) your time variables are going to have to account for location as well.

As such, you might have to have a look at the DateTimeZone class

DateTimeZone

Robotnik
  • 3,643
  • 3
  • 31
  • 49