MATLAB: Datetime ‘UTCLeapSeconds’, 2 second difference across leap sec boundary

datetimegpsleap secondutcleapseconds

I was recently made aware of the leap second capability in the new datetime class of R2014b, so I did some simple tests and did not get the expected results. Am I doing something wrong or is the leap second adjustment wrong?
1st case is two dates surrounding a June 30 that did NOT have a leap second, 2013, and using the 'UTC' for TimeZone:
>> t3 = datetime(2013,6,30,0,0,0)
t3 = 
   30-Jun-2013 00:00:00
>> t3.TimeZone = 'UTC'
t3 = 
   30-Jun-2013 00:00:00
>> t4 = datetime(2013,7,2,0,0,0)
t4 = 
   02-Jul-2013 00:00:00
>> t4.TimeZone = 'UTC'
t4 = 
   02-Jul-2013 00:00:00
>> seconds(t4-t3) - 2*86400
ans =
     0
Exactly two 86400 second days as expected. All well and good.
2nd case is two dates surrounding a June 30 that DID have a leap second, 2012, and using the 'UTCLeapSeconds' for TimeZone:
>> t1 = datetime(2012,6,30,0,0,0)
t1 = 
   30-Jun-2012 00:00:00
>> t1.TimeZone = 'UTCLeapSeconds'
t1 = 
   2012-06-30T00:00:24.000Z
>> t2 = datetime(2012,7,2,0,0,0)
t2 = 
   02-Jul-2012 00:00:00
>> t2.TimeZone = 'UTCLeapSeconds'
t2 = 
   2012-07-02T00:00:25.000Z
>> seconds(t2-t1) - 2*86400
ans =
     2
So the 24.000 and 25.000 that are showing up in the date displays match the total number of leap seconds that have been applied through those dates (e.g., see http://en.wikipedia.org/wiki/Leap_second). So that seems to match. But when I look at the difference I get 2 seconds instead of the expected 1 second across this applied leap second boundary. What am I missing here? Am I building the dates or applying the UTCLeapSeconds TimeZone incorrectly? Or what?
3rd case is two dates surrounding a June 30 that DID have a leap second, 2015, but is announced in the future, again using the 'UTCLeapSeconds' for TimeZone:
>> t5 = datetime(2015,6,30,0,0,0)
t5 = 
   30-Jun-2015 00:00:00
>> t5.TimeZone = 'UTCLeapSeconds'
t5 = 
   2015-06-30T00:00:25.000Z
>> t6 = datetime(2015,7,2,0,0,0)
t6 = 
   02-Jul-2015 00:00:00
>> t6.TimeZone = 'UTCLeapSeconds'
t6 = 
   2015-07-02T00:00:25.000Z
>> seconds(t6-t5) - 2*86400
ans =
     0
So the announced leap second is not accounted for here (obvious from looking at the 25.000 in the t6 date instead of the expected 26.000). So what is the process for keeping the datetime function up-to-date for leap second adjustments? This needs to be a table look up of some sort in the background, so how does one get/keep this updated? I didn't see anything in the doc that mentions this.

Best Answer

James, in the second instance, you're subtracting 2012-06-30T00:00:24.000Z from 2012-07-02T00:00:25.000Z. There really is 86401+86400+1 seconds difference, i.e. 2*86400 + 2, because of the one leap second and the 1s diffference in the times of day. I think the confusion stems from the diff between what you did and this:
>> t1 = datetime(2012,6,30,0,0,0,'TimeZone','UTCLeapSeconds')
t1 = 
   2012-06-30T00:00:00.000Z
>> t2 = datetime(2012,7,2,0,0,0,'TimeZone','UTCLeapSeconds')
t2 = 
   2012-07-02T00:00:00.000Z
>> t2 - t1
ans = 
   48:00:01
That's 48h and 1s. I will make a note to look into the conversion from "unzoned" to 'UTCLeapSeconds', and why you get those extra seconds.
In the third case, you're running 14b, which was released before the 2015 leap second was even announced. There was a patch posted in early January, and the recently-released 15a has the patch already in it. You're right, there needs to be more communication about how to update, although given the current state of affairs, it's not even clear that there will ever be any more leap seconds.
Hope this helps.
Related Question