2

I am working with an embedded Linux (ARM/busybox) system. It has systemd and the timedatectl system executable, but it does not have /etc/timezone, /usr/share/zoneinfo, nor the zic timezone data compiler program.

I have plenty of system diskspace on this embedded system.

Is it possible to copy the /usr/share/zoneinfo contents from an amd64 Linux implementation to my embedded ARM Linux implementation "as-is" to get access to the timezone functionality that timedatectl provides?

Thanks for your help.

3 Answers 3

3

Yes, the binary timezone files are platform-agnostic.

This is noted e.g. in the Wikipedia article "tz database":

The tz database is published as a set of text files which list the rules and zone transitions in a human-readable format. For use, these text files are compiled into a set of platform-independent binary files—one per time zone. The reference source code includes such a compiler called zic (zone information compiler), as well as code to read those files and use them in standard APIs such as localtime() and mktime().

The binary format itself is documented in the manpage tzfile(5) and RFC 8536:

The timezone information files used by tzset(3) are typically found under a directory with a name like /usr/share/zoneinfo. These files use the format described in Internet RFC 8536. Each file is a sequence of 8-bit bytes. In a file, a binary integer is represented by a sequence of one or more bytes in network order (bigendian, or high-order byte first), […]

There might be some incompatibility if the reading library is much older than zic, depending on with which parameters zic was run:

-b bloat
Output backward-compatibility data as specified by bloat. If bloat is fat, generate additional data entries that work around potential bugs or incompatibilities in older software, such as software that mishandles the 64-bit generated data. If bloat is slim, keep the output files small; this can help check for the bugs and incompatibilities. Although the default is currently fat, this is intended to change in future zic versions, as software that mishandles the 64-bit data typically mishandles timestamps after the year 2038 anyway. Also see the -r option for another way to shrink output size.

1

I ended up creating a tarball of /usr/share/zoneinfo/ from an Ubuntu system, copied it and unzipped it on the embedded system, and the following "just worked."

So it seems the /usr/share/zoneinfo is platform agnostic.

root@mityomapl138:~# timedatectl set-timezone America/New_York
root@mityomapl138:~# timedatectl
Warning: ignoring the TZ variable, reading the system's timezone setting only.

      Local time: Thu 2024-01-18 11:13:37 EST
  Universal time: Thu 2024-01-18 16:13:37 UTC
        RTC time: Thu 2024-01-18 16:13:37
        Timezone: America/New_York (EST, -0500)
     NTP enabled: n/a
NTP synchronized: yes
 RTC in local TZ: no
      DST active: no
 Last DST change: DST ended at
                  Sun 2023-11-05 01:59:59 EDT
                  Sun 2023-11-05 01:00:00 EST
 Next DST change: DST begins (the clock jumps one hour forward) at
                  Sun 2024-03-10 01:59:59 EST
                  Sun 2024-03-10 03:00:00 EDT
1

Your question is specifically about /usr/share/zoneinfo, but it can be answered more generally: /usr/share is intended for files which are platform-independent. This is codified for example in the Filesystem Hierarchy Standard:

The /usr/share hierarchy is for all read-only architecture independent data files.

This hierarchy is intended to be shareable among all architecture platforms of a given OS; thus, for example, a site with i386, Alpha, and PPC platforms might maintain a single /usr/share directory that is centrally-mounted. Note, however, that /usr/share is generally not intended to be shared by different OSes or by different releases of the same OS.

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.