Summary of important user-visible changes for datatypes 1.3.3:
--------------------------------------------------------------

 This release widens the years `datetime` can represent, from [-32767, 32767]
 to any year its components can hold, and fixes the defects found in testing
 it.  Several of those are wrong at ordinary dates.

 ** `datetime` carries any year.  Components, every `'ConvertFrom'`
    conversion, the instant conversions, orderings, set operations and both
    arithmetics work at year 1e6 and 1e9 and their negatives, matching
    R2026a.  Such a year previously aborted the interpreter or gave a wrong
    date.

 ** Time zones resolve for any year, by extrapolating the database's own rule
    across its exact 400-year period, as MATLAB does.

 ** `datetime` reads a year of more than four digits from text, and a
    negative one, both with a detected format and with `'InputFormat'`.

 ** Fixed-length arithmetic keeps the microsecond at any year.  Adding
    `milliseconds (0.001)` did not move the value from about year 3000, and
    two clocks a microsecond apart subtracted to zero.

 ** A `datenum` or Excel serial converts back to the time it was made from;
    it gave 10:30:44.999997 for 10:30:45.  `exceltime` now counts from
    Excel's own epoch rather than through `datenum`, which cost sixteen times
    the precision.

 ** An unzoned `datetime` is no longer resolved against the machine's
    timezone.  A wall clock in that machine's spring-forward gap was moved,
    so the same code gave different answers on different machines.

 ** Negative time components carry the right number of days:
    `datetime (2024, 3, 15, -24, 0, 0)` landed on 13 March rather than 14, and
    the matrix spelling took no day at all.

 ** An element assigned from another time zone is converted into the array's
    zone, as concatenation already did.  Assignment between a zoned array and
    an unzoned one, or across the leap-second timeline, is now refused.

 ** A `datetime` column survives `writetable` and `readtable` at any year; a
    column holding year 1e6 came back as `NaT`.

 ** Text rendered with a zero-padded year can be read back:
    `char (T, 'uuuuuuuu-MM-dd')` emitted text the same format then refused.

 ** `histcounts` refuses a bin width where a bin count belongs, in both
    `datetime` and `duration`; on a duration array `days (2)` asked for
    172800000 bins.  Give a width through `'BinWidth'`.

 ** `writetable` and `readtable` use Excel's 1900 date system, which counts a
    29 February 1900 that never existed; dates before 1900-03-01 were a day
    out against files from Excel, MATLAB or LibreOffice.  Files written by
    1.3.2 or earlier cannot be repaired, only rewritten.

 ** `table` is installable again (issue #52).

 Deliberate deviations from MATLAB, documented in each function's help text:

 ** A year in text is read as far as the calendar goes; MATLAB stops at six
    significant digits and so cannot read back its own `writetable` output.

 ** A distant year is rendered in the format asked for, not as `1000000 CE`.

 ** A zone resolves for any year, where MATLAB raises past about 144684.

 ** An infinite `datetime` is infinite in every component; MATLAB reports the
    year alone as infinite with `NaN` elsewhere, a tuple its own constructor
    reads back as `NaT`.

 ** `exceltime (T, '1904')` returns a plain day count, so a date before
    1900-03-01 gets a serial one greater than MATLAB's, which carries the
    phantom 29 February 1900 into the system that exists to avoid it.

 ** A date below Excel's serial 0 is written to `.xlsx` as ISO 8601 text, as
    MATLAB does, but spelled ISO rather than in the display format.
