We have a new, improved string type coming up in AK (OOM aware, no null
state), and while it's going to use UTF-8, the name UTF8String is a
mouthful - so let's free up the String name by renaming the existing
class.
Making the old one have an annoying name will hopefully also help with
quick adoption :^)
On Fedora Silverblue and other OSTree-based systems, /etc/localtime is
a symlink to /run/host/etc/localtime, which then points to the expected
zoneinfo file, e.g. ../usr/share/zoneinfo/Europe/Berlin.
By using realpath() instead of readlink() we can resolve the symlink
recursively and avoid falling back to UTC.
Commit c3fd455 changed LibTimeZone to fall back to the system time zone
when we fail to parse the TZ environment variable. This behavior differs
from both our LibC and glibc; they abort parsing and default to UTC.
This changes LibTimeZone to behave the same way to avoid a very awkward
situation where some parts of the codebase thinks the timezone is UTC,
and others think the timezone is whatever /etc/timezone indicates.
We have logic for serenity_generated_sources which works well for source
files that are specified in GENERATED_SOURCES prior to calling
serenity_lib or serenity_bin. However, code generated with
invoke_generator, and the LibWeb generators do not always follow the
pattern of the IDL and GML files.
For the LibWeb generators, we can just add_dependencies to LibWeb at the
time we declare the generate_Foo custom target. However for LibLocale,
LibTimeZone, and LibUnicode, we don't have the name of the target
available, so export the name in a variable to set into
GENERATED_SOURCES.
To make this work for Lagom, we need to make sure that lagom_lib and
serenity_bin in Lagom/CMakeLists.txt call serenity_generated_sources on
the target.
This enables the Xcode generator on macOS hosts, at least for Lagom.
The tzname array stores the abbreviated names of the current time zone
when in standard and daylight time. These abbreviations are ambiguous;
a single abbreviation often maps to multiple time zones. For example,
EST is used by America/New_York and America/Detroit, and CST could be
the abbreviation of Central Standard Time or China Standard Time.
Instead, we mimic a subset of how both ICU and Howard Hinnant's "date"
library determines the current time zone. First, we try to parse the TZ
environment variable. If that fails, or isn't set, we try to resolve the
/etc/localtime symbolic link. On most Linux systems and on macOS, this
is a link to the current TZDB file in use.
If all of the above fails, we fall back to UTC.
This commit moves the length calculations out to be directly on the
StringView users. This is an important step towards the goal of removing
StringView(char const*), as it moves the responsibility of calculating
the size of the string to the user of the StringView (which will prevent
naive uses causing OOB access).
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 option sets -fprofile-instr-generate -fcoverage-mapping for Clang
builds only on almost all of Userland. Loader and LibTimeZone are
exempt. This can be used for generating code coverage reports, or even
PGO in the future.
This renames the current implementation of current_time_zone to
system_time_zone to more clearly indicate what it is. Then reimplements
current_time_zone to return whatever was set up by tzset, falling back
to UTC if something went awry, for convenience.
This changes LibTimeZone to read the current time zone from the file
/etc/timezone rather than using tzset/tzname. Instead, in a subsequent
commit, LibC's time methods will be changed to used LibTimeZone to
retrieve the system time zone.
Also add an API to set the system time zone. This method is only allowed
when running within Serenity.
LibTimeZone will be needed directly within LibC for functions such as
localtime(). This change adds LibTimeZone directly within LibC, so that
LibTimeZone isn't its own .so library anymore.
LibTimeZone itself is compiled as an object library to make it easier to
give it generator-specific compilation flags.
If the tzname is unknown, fall back to UTC for now. Unknown time zones
are most likely due to not parsing RULE entries yet, but at the very
least, it only makes sense for current_time_zone to return a time zone
that LibTimeZone actually knows about.
Instead of only having dummy functions that don't work with any input,
let's at least support one time zone: 'UTC'. This matches the basic
Temporal implementation for engines without ECMA-262, for example.
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".
This CMakeLists.txt was basically copy-pasted from LibUnicode, where the
generated data is separated into its own library. This was to let other
libraries / applications decide if they actually want to link the data
because it is so large. LibTimeZone's generated data is significantly
smaller, so this separation really isn't needed.
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.
