Africa/Casablanca transitions is incorrectly calculated starting from 2027

The 'sun/util/calendar/zi/TestZoneInfo310.java' test failures were observed during latest tzdata2014e integration into JDK9.
The first failure is related to the internal representation of the '24:00' value. The JSR310 implementation treats this value as a 'day+1 00:00' value.
Test fails with such error:
    sun/util/calendar/zi/TestZoneInfo310.java TZ failure:
       stz=java.util.SimpleTimeZone[id=ART,offset=7200000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=3,startDay=-1,startDayOfWeek=6,startTime=0,startTimeMode=1,endMode=2,endMonth=8,endDay=-1,endDayOfWeek=6,endTime=0,endTimeMode=0]
      stz0=java.util.SimpleTimeZone[id=ART,offset=7200000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=3,startDay=-1,startDayOfWeek=6,startTime=0,startTimeMode=1,endMode=2,endMonth=8,endDay=-1,endDayOfWeek=5,endTime=86400000,endTimeMode=0]
The workaround already exists in JSR310 code for similar entries and this failure will be resolved in similar way as part of tzdata2014e update (see JDK-8049343 for details).

Second failure can be observed after first problem is fixed. The Africa/Casablanca transitions is incorrectly calculated starting from 2027:
Africa/Casablanca : Africa/Casablanca
offset=0,dstSavings=0,useDaylight=false,transitions=83,offsets=3,checksum=-918774076,gmtChanged=false
[NG]offset=0,dstSavings=3600000,useDaylight=false,transitions=103,offsets=3,checksum=450727553,gmtChanged=false
    -------------
    (NG) Different trans size :83, 103

The full test output is attached for this failure is attached.