Compilation of tzdata 2013h to 2015d fails

[omus]

During the development of #155 it was noticed that the TimeZones.jl 0.8.0 release cannot parse the 2013h to 2015d tzdata releases. The error that appears isn't very helpful:

ERROR: Dates are probably not in order

Upon further investigation the issue has to do with these "Morocco" rules:

Rule	Morocco	2038	only	-	Oct	 30	 2:00	1:00	S
Rule	Morocco	2038	max	-	Oct	 lastSun 3:00	0	-

These rules end up resolving to 2038-10-30 and 2038-10-31 which are close enough that we may run into issues with the partial information we have at this time.

The rules for these future transitions were revised as of 2015e. The release notes mention some changes regarding Morocco but not that far into the future:

Morocco will suspend DST from 2015-06-14 03:00 through 2015-07-19 02:00,
not 06-13 and 07-18 as we had guessed. (Thanks to Milamber.)

The reason this problem exists in the first place is due to the how we calculate the UTC transition timestamps. We need to apply the appropriate zone and various rules in the correct order. Determining order is rather tricky early on so we perform a calculation without taking into account the UTC offset and DST offset and ensure to fail safe by making sure that two calculations don't occur so close that they could possibly be in the wrong order. At the moment we use ~35 hours as being too close which is calculated from the max/min of all of the known time zones. We could do better here by just looking at the offsets associated with the zone and rules when performing ordering.

[Nosferican]

Is this still relevant?

[omus]

Failure is still present with TimeZones 1.0.1. Although these are older versions of tzdata I'd like to make sure we can parse these correctly as newer versions of tzdata may cause us to run into this problem again.