Some time zones, like "Asia/Shanghai", use a set of DST rules that end
before present day. In these cases, we should fall back to last possible
RULE entry from the TZDB. The time zone compiler published by IANA (zic)
performs the same fallback starting with version 2 of the time zone file
format.
Rather than invoking AK::Time::from_timestamp at runtime, we can do so
at compile time. This reduces invoking TimeZone::get_time_zone_offset
100,000 times in a loop from about 7 seconds to 30 milliseconds.
Currently, the unique string lists are stored in the initialized data
sections of their shared libraries. In order to move the data to the
read-only section, generate the strings using RLE arrays.
We generate two arrays: the first is the RLE data itself, the second is
a list of indices into the RLE array for each string. We then generate a
decoding method to convert an RLE string to a StringView.
Each of these strings would previously rely on StringView's char const*
constructor overload, which would call __builtin_strlen on the string.
Since we now have operator ""sv, we can replace these with much simpler
versions. This opens the door to being able to remove
StringView(char const*).
No functional changes.
The zone1970.tab file in the TZDB contains regional time zone data, some
of which we already parse for the system time zone settings map.
This parses the region names from that file and generates a list of time
zones which are used in each of those regions.
This commit has no behavior changes.
In particular, this does not fix any of the wrong uses of the previous
default parameter (which used to be 'false', meaning "only replace the
first occurence in the string"). It simply replaces the default uses by
String::replace(..., ReplaceMode::FirstOnly), leaving them incorrect.
Similar reasoning to making Core::Stream::read() return Bytes, except
that every user of read_line() creates a StringView from the result, so
let's just return one right away.
Day and month name constants are defined in numerous places. This
pulls them together into a single place and eliminates the
duplication. It also ensures they are `constexpr`.
This also moves the open_file helper to the utility file. It's currently
a lambda redefined in each TZDB/Unicode generator. It used to display
the missing command line flag and other info local to each generator.
After switching to LibMain, it just returns a generic error message, and
is duplicated several times.
Added the call to generate_available_values(), then realized it is the
exact same as the existing, manually written implementation. So let's
use the new utility.
This just splits up the method to find the active DST rule for specified
time and time zone. This is to allow re-using the now split-off function
in upcoming commits.
For example, today, America/New_York has the format string "E%sT" and
uses US DST rules. Those rules indicate the %s should be replaced by a
"D" in daylight time and "S" in standard time.
Each ZONE entry contains a RULES segment with one of the following:
* A DST rule name, which links the ZONE to a RULE entry holding the
DST rules to apply.
* A static offset to be applied to the STDOFF offset. This implicitly
means that the time zone is in DST during that time frame.
* A "-" string, meaning no offset is applied to the STDOFF offset, and
the time zone is in standard time during that time frame.
This is a rather naive implementation, but serves as a first pass at
determining the GMT offset for a time zone at a particular point in
time. This implementation ignores DST (because we are not parsing any
RULE entries yet), and ignores any offset patterns of the form "Mon>4"
or "lastSun".
For example, generate "Etc/GMT+12" as "Etc_GMT_Ahead_12" (instead of as
"Etc_GMT_P12"). A little clearer what the name means without having to
know off-hand what "P" was representing.
When compiled using clang, an ambiguity error is detected between
`class AK::Time` aliased to `::Time` and the `struct ::Time` provided
in `GenerateTimeZoneData.cpp`. Solve this by moving most of the code in
an anonymous namespace.
The IANA Time Zone Database contains data needed, at least, for various
JavaScript objects. This adds plumbing for a parser and code generator
for this data. The generated data will be made available by LibTimeZone,
much like how UCD and CLDR data is available through LibUnicode.
