Releases: bxparks/AceTime
Releases · bxparks/AceTime
2.3.2 - upgrade to TZDB 2024a
- 2.3.2 (2024-07-25, TZDB version 2024a)
- Upgrade TZDB to 2024a
- https://mm.icann.org/pipermail/tz-announce/2024-February/000081.html
- "Kazakhstan unifies on UTC+5 beginning 2024-03-01. Palestine springs
forward a week later after Ramadan. zic no longer pretends to support
indefinite-past DST. localtime no longer mishandles Ciudad Jurez in
2422."
- Increase minimum python version to 3.10.
- Upgrade TZDB to 2024a
2.3.1 - upgrade to TZDB 2023d
- 2.3.1 (2024-01-12, TZDB version 2023d)
- Upgrade TZDB to 2023d
- https://mm.icann.org/pipermail/tz-announce/2023-December/000080.html
- "Ittoqqortoormiit, Greenland changes time zones on 2024-03-31. Vostok,
Antarctica changed time zones on 2023-12-18. Casey, Antarctica changed
time zones five times since 2020. Code and data fixes for Palestine
timestamps starting in 2072. A new data file zonenow.tab for
timestamps starting now."
- Upgrade TZDB to 2023d
2.3.0 - add CompleteZoneManager, zonedbc to extend timezone year range to [0001,10000)
Major Changes in v2.3: Add CompleteZoneProcessor
, CompleteZoneManager
,
and the zonedbc
database to support all timezones, for all transitions defined
in the IANA TZ database ([1844,2087])
, and extending the validity of timezone
calculations from [2000,10000)
to [0001,10000)
.
Migration: MIGRATING.md
Changelog
- 2.3.0 (2023-06-27, TZDB version 2023c)
- Create CustomZoneRegistry example
to illustrate how to use a custom registry. - Update
BasicZoneManager
to detect gaps.- Allows
AceTimeValidation/validation
tests to pass. - Still not able to distinguish between exact and overlap though.
- Allows
- Allow multi-character
ZoneRule.letter
inBasicZoneProcessor
.- Regenerate
zonedb
which enables 2 more zones:/Africa/Windhoek
,
andAmerica/Belize
- Increases
zonedb
by 150-200 bytes.
- Regenerate
- Rename
BrokerFactory
toZoneInfoStore
for better self-documentation.- This is an internal implementation detail. Downstream clients should
not be affected.
- This is an internal implementation detail. Downstream clients should
ZoneContext
- Move
ZoneContext
,letters[]
,fragments[]
into PROGMEM. - Move
zonedbXxx::kTzDatabaseVersion
string into PROGMEM, and change
type toconst __FlashString*
. - Create
ZoneContextBroker
aroundZoneContext
, for consistency
with all other zoneinfo data structures. MergeZoneContext.h
into
ZoneInfo.h
. - Add
startYearAccurate
anduntilYearAccurate
toZoneContext
which
define the interval of accurate transitions. - Saves around 150-200 bytes of RAM on AVR processors,
200-350 bytes of RAM on ESP8266.
- Move
- Cleanly separate zoneinfo storage classes from their brokers classes.
- Three storage implementations instead of one:
zoneinfolow
,
zoneinfomid
,zoneinfohigh
, supporting low, middle, and high time
resolutions. zoneinfohigh
was created to supportCompleteZoneProcessor
,
CompleteZoneManager
and thezonedbc
database.zoneinfomid
initially used inExtendedZoneProcessor
, but now
unused.- Merge
zoneinfo/ZonePolicy.h
intozoneinfo/ZoneInfo.h
. - Convert structs in
zoneinfo/ZoneInfo.inc
into templates, with
synthetictypename S
selector. MergeZoneInfo.inc
into
ZoneInfo.h
.
- Three storage implementations instead of one:
- Support timezones before 1972 using
CompleteZoneManager
,
CompleteZoneProcessor
, andzonedbc
database- Before standardizing on UTC around 1970, many timezones had local
times offsets from UTC which require one-second resolution instead of
one-minute resolution. This requires changing many internal variables
fromint16_t
toint32_t
. - Change
TimeOffset
to support one-second resolution usingint32_t
. - Rename
BasicZone::stdOffseMinutes()
toBasicZone::stdOffset()
which returns aTimeOffset
object. - Rename
ExtendedZone::stdOffseMinutes()
to
ExtendedZone::stdOffset()
which returns aTimeOffset
object. - Leave
BasicZoneProcessor
using one-minute resolution because its
algorithm has an inherent limitations which cannot handle many
timezones before 1972, so no need to convertint16_t
toint32_t
fields. - Add
CompleteZoneManager
,CompleteZoneProcessor
,
CompleteZoneProcessorCache
,CompleteZone
- Add
zonedbc
database which is valid from[1800,10000)
, which
includes all transitions in the TZDB since the first transition is
1844. - Add
scope=complete
to access thezonedbc
database.
- Before standardizing on UTC around 1970, many timezones had local
- Zone Processor with graceful degradation
- Remove range checks against
ZoneContext.startYear()
and
ZoneContext.untilYear()
- Replace with
LocalDate::kMinYear
andLocalDate::kMaxYear
, mostly
for formatting reasons (prevent negative
years, and years with more than 4 digits). - The zone processors will always return something reasonble across the
entireint16_t
range. - Only the accuracy suffers outside of the
startYearAccurate()
and
untilYearAccurate()
limits. - Along with v2.2 which always generates anchor rules for all zone
policies, thestartYearAccureate()
anduntilYearAccurate()
allows
for graceful degradation of classes likeZonedDateTime
for years
outside of this accuracy range.
- Remove range checks against
- Rename
src/tzonedb*
directories- to
src/zonedb*testing
for consistency with other acetime libraries
- to
- Create CustomZoneRegistry example
2.2.3 - auto zone processor cache invalidation; add SAMD21, SAMD51 back into Tier 1 suport
- 2.2.3 (2023-05-31, TZDB version 2023c)
- Update
ace_time/testing/*
classes to support splitting the test data
into 2 separate lists:transitions
andsamples
.- Required to support new
validation_data.json
from AceTimeValidation.
- Required to support new
- Update
AceTimeValidation
test names totests/Xxx{Basic,Extended}Test
. - Add
ZonedExtra::kAbbrevSize
to define thechar
buffer size needed to
hold an abbreviation. - Change
ZonedExtra::kInvalidMinutes
from public to private.- This is an implementation detail.
- Use
ZonedExtra::isError()
instead.
- Rename AceTimePython to acetimepy.
- ZoneProcessor transition cache
- Save the epoch year, and automatically invalidate and regenerate the
cache when theEpoch::currentEpochYear()
is modified. - Remove cache invalidation methods which are no longer needed:
ZoneProcessor::resetTransitionCache()
ZoneProcessorCache::resetZoneProcessors()
ZoneManager::resetZoneProcessors()
- Save the epoch year, and automatically invalidate and regenerate the
- Rename "Converter Epoch" to "Internal Epoch".
- Change
daysToCurrentEpochFromConverterEpoch()
to
daysToCurrentEpochFromInternalEpoch()
. - This is an internal implementation detail, exposed only for testing
purposes.
- Change
- Update supported boards and tiers
- Add SAMD21 and SAMD51 boards to Tier 1
- Add Adafruit ItsyBitsy M4 (SAMD51 120MHz ARM Cortex-M4)
- SAMD21 and SAMD51 boards are back in Tier 1, as long as they use
the traditional Arduino API instead of the new
Arduino-Core. - Fortunately most third party SAMD21 and SAMD51 boards continue to
use the traditional Arduino API.
- Move Teensy 3.2 to Tier 2
- This board is entering end-of-life.
- As well, the Teensyduino environment integrates with the Arduino
IDE and CLI in a way that's different than all other third-party
Arduino boards. Some of my automation scripts do not work with
Teensyduino, so it becomes very time consuming to test the Teensy
boards. - All Teensy boards are now in Tier 2 ("Should work but not tested
often").
- Add SAMD21 and SAMD51 boards to Tier 1
- Update
2.2.2 - upgrade to TZDB 2023c
- 2.2.2 (2023-04-01, TZDB version 2023c)
- Upgrade TZDB from 2023b to 2023c.
- https://mm.icann.org/pipermail/tz-announce/2023-March/000079.html
- "This release's code and data are identical to 2023a. In other
words, this release reverts all changes made in 2023b other than
commentary, as that appears to be the best of a bad set of
short-notice choices for modeling this week's daylight saving
chaos in Lebanon."
- "This release's code and data are identical to 2023a. In other
- https://mm.icann.org/pipermail/tz-announce/2023-March/000079.html
- AceTime is forced to upgrade to 2023c, because we skipped 2023a and went
directly to 2023b, which is being rolled back by 2023c.
- Upgrade TZDB from 2023b to 2023c.
2.2.1 - upgrade to TZDB 2023b; immutable TimeZone; support SAMD21 again
- 2.2.1 (2023-03-24, TZDB version 2023b)
- Actually regenerate the
zonedb*
files to 2023b.
- Actually regenerate the
- 2.2.0 (2023-03-24, TZDB version 2023b)
- Upgrade TZDB from 2022g to 2023b
- 2023a skipped because it came out only a day earlier.
- 2023a: https://mm.icann.org/pipermail/tz-announce/2023-March/000077.html
- Egypt now uses DST again, from April through October.
- This year Morocco springs forward April 23, not April 30.
- Palestine delays the start of DST this year.
- Much of Greenland still uses DST from 2024 on.
- America/Yellowknife now links to America/Edmonton.
- tzselect can now use current time to help infer timezone.
- The code now defaults to C99 or later.
- Fix use of C23 attributes.
- 2023b: https://mm.icann.org/pipermail/tz-announce/2023-March/000078.html
- Lebanon delays the start of DST this year.
- Bug Fix
- Change arguments for
TimeZone::forMinutes()
fromuint8_t
to
uint16_t
.
- Change arguments for
- Breaking Change
- Make
TimeZone
effectively immutable, by removingsetStdOffset()
andsetDstOffset()
methods. - Client applications should create a new
TimeZone
object using
TimeZone::forTimeOffset(std, dst)
and overwrite the old one. - See Migrating to v2.2.
- Make
- Add support for Seeed Studio XIAO M0 (SAMD21).
- Required updating
zoneino/compat.h
to clobber the broken definition
ofFPSTR()
in Seeeduino 1.8.3.
- Required updating
- Simplify the handling of
Rule.LETTER
.- Encode all letters as an index into
ZoneContext.letters
array, not
justLETTER
which are only a single character. - On 8-bit AVR:
- Increases
BasicZoneProcessor
by ~200 bytes when 1-2 zones are
used. But flash remains the same when the full TZ database is
used. - No change to
ExtendedZoneProcessor
for 1-2 zones. But decreases
flash usage by ~300 bytes when the full TZ database is used.
- Increases
- The small increase in flash is worth it because this greatly
simplifies the complicated code surrounding LETTER that was difficult
to understand and maintain.
- Encode all letters as an index into
- Unify Basic and Extended zoneinfo encoding.
- Change encoding of
basic::ZoneRule.deltaCode
,
basic::ZoneEra.deltaCode
, andbasic::ZoneEra.offsetCode
to be
identical their counterparts inextended::ZoneXxx
. - Merge
BasicBrokers.h
andExtendedBrokers.h
into justBrokers.h
.
- Change encoding of
- Restructure zonedb directories
- Lift
ace_time/internal/testing/tzonedb[x]
database files
toace_time/tzonedb[x]
. - Lift
ace_time/zonedb[x]
database files toace_time/zonedb[x]
. - These changes are transparent to client apps because the C++
namespaces of these files are unchanged. - Lift
ace_time/internal/Zone*.h
files into newsrc/zoneinfo/
directory. These are the classes that describe the*zonedb*
databases.
- Lift
- Add
ZonedDateTime::offsetDateTime()
- Returns the underlying
OffsetDateTime
inside theZonedDateTime
. - Analogous to
ZonedDateTime::localDateTime()
.
- Returns the underlying
- Always generate anchor rules in zonedb.
- Allows
ExtendedZoneProcessor
to work over all years[0,10000)
even with truncated zonedb (e.g.[2000,2100)
). - Accuracy is guaranteed only for the requested interval (e.g.
[2000,2100)
. - But the code won't crash outside of that interval.
- Allows
- Upgrade TZDB from 2022g to 2023b
2.1.1 - update AutoBenchmark; add ZonedExtra::forComponents() for consistency
- 2.1.1 (2023-02-02, TZDB version 2022g)
ZonedExtra
- Add
ZonedExtra::forComponents()
factory method, for consistency with
ZonedDateTime
class.
- Add
examples/AutoBenchmark
- Add
ZonedExtra
benchmarks.
- Add
README.md
- Update
AceTimeValidation
validation years to[2000,2100)
. - Update memory and cpu benchmarks.
- Update
v2.1.0 - unified links; simplify TimeZone using ZonedExtra class
- 2.1.0 (2023-01-29, TZDB version 2022g)
- There are a handful API breaking changes in this release in the pursuit of
simpler and cleaner code. See the following for more info:- Migrating to v2.1
- ZonedExtra in the User Guide
- Unified Links in the User Guide
- Potentially Breaking: zonedb,zonedbx
- Rename
kPolicyXxx
tokZonePolicyXxx
for consistency. These are
expected to be used only internally, so shouldn't cause external
breakage.
- Rename
- Breaking:
TimeZone.h
- Replace 3 separate extraction methods in
TimeZone
with a new
ZonedExtra
class - Removed:
TimeZone::getUtcOffset()
- Replaced by:
ZonedExtra::timeOffset()
- Replaced by:
- Removed:
TimeZone::getDeltaOffset()
- Replaced by:
ZonedExtra::dstOffset()
- Replaced by:
- Removed
TimeZone::getAbbrev()
- Replaced by:
ZonedExtra::abbrev()
ZonedExtra::abbrev()
returns pointer to a local string buffer
instead of a transient buffer deep insideTransition
object.TimeZone
becomes closer to being thread-safe
- Replaced by:
- Replace 3 separate extraction methods in
- New Class:
ZonedExtra.h
ZonedExtra::forEpochSeconds(epochSeconds, tz)
- Create instance from epochSeconds and time zone.
ZonedExtra::forLocalDateTime(ldt, tz)
- Create instance from LocalDateTime and time zone.
- Potentially Breaking: Unified Links
- Links are now first-class citizens, exactly the same as Zones.
- Unify "fat links" and "symbolic links" into a single implementation.
- Remove "thin links" to simplify the code.
TimeZone
class simplified- Removed
followLink
flag on various methods. - Only 2 methods apply to Links:
isLink()
and
printTargetNameTo()
.
- Removed
- Simplify ZoneProcessors
ZoneProcessor.h
,ExtendedZoneProcessor.h
,BasicZoneProcessor.h
- Remove:
getUtcOffset()
,getDeltaOffset()
,getAbbrev()
- Replaced by:
findByLocalDateTime()
,findByEpochSeconds()
- These are internal helper methods not intended for public consumption.
- Unit tests
- Migrate most unit tests to use the smaller, testing zone databases at
testing/tzonedb/
andtesting/tzonedbx/
.- Reduces maintenance cost of various hand-crafted ZoneInfo and
ZonePolicy entries for unit tests. - Can test against real timezones with predictable behavior.
- Reduces maintenance cost of various hand-crafted ZoneInfo and
- Migrate most unit tests to use the smaller, testing zone databases at
- There are a handful API breaking changes in this release in the pursuit of
2.0.1 - upgrade to TZDB 2022g; include notable policies in notable zones comments
- 2.0.1 (2022-12-04, TZDB 2022g)
- Prevent
ExtendedZoneProcssor::generateStartUntilTimes()
from
dereferencing uninitialized memory if there are no matching transitions.- This may happen if
zonedbx
is accidentally corrupted (e.g. by using
one withint8
year fields instead ofint16
year fields).
- This may happen if
- Incorporate notable
zone_policies.h
comments into notable
zone_infos.h
. - Upgrade TZDB from 2022f to 2022g
- https://mm.icann.org/pipermail/tz-announce/2022-November/000076.html
- The northern edge of Chihuahua changes to US timekeeping.
- Much of Greenland stops changing clocks after March 2023.
- Fix some pre-1996 timestamps in northern Canada.
- C89 is now deprecated; please use C99 or later.
- Portability fixes for AIX, libintl, MS-Windows, musl, z/OS
- In C code, use more C23 features if available.
- C23 timegm now supported by default
- Fixes for unlikely integer overflows
- https://mm.icann.org/pipermail/tz-announce/2022-November/000076.html
- Prevent
expand timezone support from [2000,2050) to [2000,2100); allow adjustable epoch year
- 2.0 (2022-11-04, TZDB 2022f) Breaking Change See
Migrating to 2.0.0- Change internal storage type of
year
component fromint8_t
to
int16_t
, extending the range of valid years from [-1873,2127] to
[1,9999].- Remove
yearTiny()
getters and setters fromLocalDate
,
LocalDateTime
,OffsetDateTime
, andZonedDateTime
.- They were not documented except in doxygen docs.
- Remove from
LocalDate
:kInvalidYearTiny
, replaced withkInvalidYear
kMinYearTiny
, replaced withkMinYear
kMaxYearTiny
, replaced withkMaxYear
forTinyComponents()
- Remove from
LocalDateTime
forTinyComponents()
- Update AceTimeTools
to generatesrc/zonedb
andsrc/zonedbx
usingint16_t
year types.
- Remove
- Extend
untilYear
of zonedb and
zonedbx databases to 10000- databases now valid over the years
[2000,10000)
zonedbx
adds 75 additional Rules forkPolicyMorocco
(e.g.
zone "Africe/Casablanca") due to the precalculated DST shifts which
are listed in the IANA TZ DB up to the year 2087.zonedb
remains unchanged
- databases now valid over the years
- Change epoch seconds conversion algorithm
- Extract different epoch date conversion algorithms to be used/tested.
Two of them areEpochConverterJulian
andEpochConverterHinnant
EpochConverterJulian
implements the algorithms found in
wikipedia article https://en.wikipedia.org/wiki/Julian_day.EpochConverterHinnant
implements the algorithms found in
https://howardhinnant.github.io/date_algorithms.html.
- Migrate
LocalDate
to use theEpochConverterHinnant
instead of
EpochConverterJulian
.- The primary reason is that I am able to fully understand the
algorithms described inEpochConverterHinnant
. - In contrast, I have almost no understanding of the algorithms
implemented byEpochConverterJulian
.
- The primary reason is that I am able to fully understand the
- Extract different epoch date conversion algorithms to be used/tested.
- Configurable epoch year using new
Epoch
utility class- Add
Epoch::currentEpochYear()
which allows customization of the
internal epoch year at startup.- Expected to be rarely used in user applications, but somewhat
common in unit testing.
- Expected to be rarely used in user applications, but somewhat
- Add
Epoch::epochValidYearLower()
andEpoch::epochValidYearUpper()
- Defines the 100-year interval which is +/- 50 years from the
currentEpochYear()
where the epoch seconds and time zone
transition algorithms are guaranteed to be valid.
- Defines the 100-year interval which is +/- 50 years from the
- Add cache invalidation methods which must be called if
currentEpochYear()
is changed at runtime.ZoneProcessor::resetTransitionCache()
ZoneProcessorCache::resetZoneProcessors()
ZoneManager::resetZoneProcessors()
- Add
- Remove
toUnixSeconds()
andforUnixSeconds()
which use the 32-bit
versions of unix epoch seconds.- They will become invalid in the year 2038, and it's now the year 2022
so it does not seem worth maintaining these. - The 64-bit versions
toUnixSeconds64()
andforUnixSeconds64()
are
retained.
- They will become invalid in the year 2038, and it's now the year 2022
- Flash usage increases (see MemoryBenchmark for
more details:- AVR:
- BasicZoneManager increases ~200 bytes
- ExtendedZoneManager increases ~500 bytes
zonedb
increases ~1.5 kiBzonedbx
increases ~3 kiB
- ESP8266
- BasicZoneManager increases ~50 bytes
- ExtendedZoneManager increases ~150 bytes
zonedb
increases ~300 byteszonedbx
increases ~1.5 kiB
- AVR:
- Change internal storage type of