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.TimeZone = 'UTC'
>> t4 = datetime(2013,7,2,0,0,0)
>> t4.TimeZone = 'UTC'
>> seconds(t4-t3) - 2*86400
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.TimeZone = 'UTCLeapSeconds'
>> t2 = datetime(2012,7,2,0,0,0)
>> t2.TimeZone = 'UTCLeapSeconds'
>> seconds(t2-t1) - 2*86400
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.TimeZone = 'UTCLeapSeconds'
>> t6 = datetime(2015,7,2,0,0,0)
>> t6.TimeZone = 'UTCLeapSeconds'
>> seconds(t6-t5) - 2*86400
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.