I have an embedded Linux device for which the stock operating system image does not include the TZ database files usually found in /usr/share/zoneinfo.

I wish to enhance the device in order to be able to include timezone support in my application. The device does not have a package manager and does not include any of the usual timezone management utilities such as tzselect or timedatectrl. The main method for shifting data onto the device is via USB flash drive.

I have confirmed that the GLIBC library on the device has been built with timezone support included, and hacking around manually copying the TZ database from my machine onto the device and creating the various symlinks expected, I can get timezone support more or less working.

Everything I can find online regarding the TZ database install recommends using the platform's package manager, which in this case is not available. A complicating factor is that the device's manufacturers suggest that all user data be placed under the /opt directory (system directories are mounted read-only), accordingly.

I'm wanting to install the database in /opt/usr/share/zoneinfo rather than the usual /usr/share/zoneinfo, with a /usr/share/zoneinfo -> /opt/usr/share/zoneinfo symlink. This means that symlinks copied from the zoneinfo directory of my development machine won't be pointing to the right place once on target (presuming they are absolute).

So to copy the TZ database I think I need to:

  • Take a temporary copy of usr/share/zoneinfo directory on my dev. machine
  • Use the symlinks utility to convert all absolute symlinks to the relative.
  • Package the directory into an archive format that maintains symlinks.
  • Copy the archive over on a USB flash drive
  • Unpack it into the desired location.

Is there a better/standard/proper way of doing this?

NOTE: I'm using CrossControl CCPilot VS, Yocto generated Linux OS.

  • Experimenting on my ubuntu xenial machine, it appears that the zoneinfo symlinks are already relative, so a conversion isn't required – Richard Lang Jul 23 '18 at 3:59

Without knowing much more about your particular hardware and scenario I feel like the easiest course of action here would be to follow how this would be done in the Linux From Scratch project (LSF).

Linux From Scratch

The project discusses the steps here: Adding time zone data

Install and set up the time zone data with the following:

    tar -xf ../../tzdata2018e.tar.gz

    mkdir -pv $ZONEINFO/{posix,right}

    for tz in etcetera southamerica northamerica europe africa antarctica  \
              asia australasia backward pacificnew systemv; do
        zic -L /dev/null   -d $ZONEINFO       -y "sh yearistype.sh" ${tz}
        zic -L /dev/null   -d $ZONEINFO/posix -y "sh yearistype.sh" ${tz}
        zic -L leapseconds -d $ZONEINFO/right -y "sh yearistype.sh" ${tz}

    cp -v zone.tab zone1970.tab iso3166.tab $ZONEINFO
    zic -d $ZONEINFO -p America/New_York
    unset ZONEINFO


**Reference:* http://www.linuxfromscratch.org/lfs/view/development/chapter06/glibc.html

The tarball?

So the only question left would be where does one acquire that tzdata2018e.tar.gz file? More Googling turns up this page: 3.2. All Packages, and on this page are these URLs.

Time Zone Data (2018e) - 346 KB:

  • Are the binary timezone files portable? What if your target system is big endian? Or time_t type there differs from the host's? The makefile has some test for time_t compatibility but I could not understand the failure mode. To put it simple - do we have to build zic for the target and use it to generate timezone files? – ddbug Oct 7 '18 at 15:46
  • @ddbug - best way to find out would be to try. – slm Oct 7 '18 at 17:12
  • I've tried and it seems to work between Intel x64 Ubuntu and recent yocto/arago on ARM32. Had also built zic for that target (a fix is needed in the Makefile for cross compiation) – ddbug Oct 7 '18 at 17:20

Turned out to be more straightforward that I was anticipating to transfer the existing TZ database on my ubuntu xenial development machine. Packaging the zoneinfo directory as a tar archive preserved the symlinks through the copy operation, and the symlinks were all already relative, so installing the directory in an alternative location on the target device wasn't a problem.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.