This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC [PATCH] BZ#1077902: New API gettimezone


On 04/03/2014 06:26 PM, Rich Felker wrote:
>> The fundamental problem is that it would be nice to have a way
>> to query the current timezone and launch another process using the
>> same timezone despite the fact that the the other process might
>> run in a different configuration (say a chroot, or container defaulting
>> to EST5EDT).
>>
>> Why can't the POSIX TZ solve the problem using the ":character"
>> implementation-defined meaning? We already use this in glibc to
>> support ":/path/to/tz/file"
>>
>> The new gettimezone API could just return ":/path/to/tz/file"
>> which is the expected locale that should be used for current timezone.
> 
> This is a reasonable request, but it doesn't help unless you can copy
> the file into the chroot.

We are now in the realm of implementation-defined behaviour so we have
some flexibility?

On Linux you could conceivable encode the timezone compressed into the
TZ var, the largest timezone we have is less than 10kb. That would work
and allow you to pass the entire zone info to the child process without
any coordination or requirement that installed tzdata be compatible.

If you choose not to go this route you can simple document that the
tzdata in the created process must be compatible. This is much more
sensible since the zone info has been around for a long time and will
therefore be generally correct until updated.

>> The problem could be that your chroot is read-only or part of some
>> container whose core image is read-only. I don't know that we can
>> expect the caller to be able to modify the chroot, but it can
>> certainly adjust the environment to attempt to set the right timezone.
> 
> If it only knows a pathname in the outside-chroot filesystem, how is
> it supposed to translate that to an equivalent TZ inside the chroot?
> Search the zoneinfo tree for a binary-identical file?

Use the same path in the chroot and expect tzdata to be as new or newer?

It is much easier for the higher level framework to look at the package
database, determine if all the required packages are in place e.g. a
tzdata that is newer or the same as your tzdata (expecing backwards
compatibility).

You can enforce package version requirements much easier than we can
request root and read-write of the root filesystem to copy /etc/localtime.

You can then abort launching the chroot'd process if the tzdata isn't
new enough that the chroot can run with the right time.

>> What do we do then? What API or service do we offer?
> 
> TZ service would work but may be overkill...

If we made a tz service operate like ntp it would be quite nice.

In summary:

- The request is for an API that allows you to query your own
  timezone in sufficient detail to start another process with the
  same timezone or a different timezone.

  - The value returned by gettimezone could be:

    - Relative path to the zoneinfo file (requires matching tzdata).
      Absolute path to the zoneinfo file (").
    * My preferred solution.

    - Encoded copy of the zoneinfo file (requires libc that can read this).

    - Opaque token (requires coordination with tzdata).

      - Like a uuid with version for each zone.

At present the best known solutions are:

- Standardize on UTC.

- Copy /etc/localtime into the chroot.

  - Requires the ability to write to the chroot

- Read /etc/localtime, if it's version-2-format then continue
  reading the last line of the file which represents the closes
  possible POSIX TZ and use that even if that might not be as
  accurate as the zoneinfo. You can't use this if the line is
  empty.

- Use existing APIs to gather information about the current
  timezone, construct a POSIX-TZ-enviroment-variable-style
  string and use that for the chroots TZ value. Again this is
  inaccurate because it doesn't have enough information.

I need to think about this some more.

Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]