This is the mail archive of the libc-help@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 10:36 PM, Paul Eggert wrote:
> Carlos O'Donell wrote:
>> standardizing on UTC ... imposes on the developer to rewrite
>> whatever software they are using for what is an arbitrary decision
>> of "Use UTC."
> 
> Software shouldn't have to be rewritten to use UTC.  It should work
> just fine if TZ='UTC0'.  The rare application that doesn't work in
> UTC should set TZ to the value that it requires.
> 
>> Can't we do better?
> 
> glibc could do something more *complicated*, sure, but it'd be work
> and it'd be error-prone, not just in terms of our own code but in
> terms of how it'd be used in practice.  "Use UTC" is simple, is
> dog-simple to explain to operations staff, and has been the standard
> approach on collections of servers for decades.

So the answer is "Use Boost.Date_Time?"

For the record I think that it is a flaw in the API not to provide
a way for the application to both query and set the timezone.

At present glibc provides TZ/tzset to set the timezone, but the
other side of the API to query that zone info is missing.

This in turn results in rather inflexible solutions that include
suggestions like only using UTC, copying special files, or using
imprecise POSIX TZ format strings.

While I agree that using UTC simplifies things, and that it may
be the case that wide-spread use of UTC will fix these problems,
it doesn't fix the present set of problems.

The use case here is a non-UTC configured system running
applications in a chroot and wanting to launch those applications
using the same timezone as the system.

I don't see using UTC as an acceptable solution for all users,
there are costs to fixing software that can't be neglected and
saying that such software should be fixed is not the same as
fixing it. Thus there are cases where you don't want to use UTC.

In those cases it would seem to me that adding an analogous
tzget() to the tzset() would seem to fix this use case.

In this case PJ suggested gettimezone(), but that's just bikeshed
on the name of the function.

Paul, I lack the experience you have working with tzcode/tzdata.

Is something like tzget() really a bad idea?

Do we really suggest Boost.Date_Time or copying files as a 
solution?

What's the consensus?

* PJ - Needs a solution to his problem.
* Siddhesh - No comment.
* Paul Eggert - Out of glibc scope.
* Rich Felker - Maybe?
* Carlos O'Donell - API missing tzget to be used with TZ/tzset.

If the consensus is that copying /etc/localtime to the chroot
or container is the right answer then that's what I'll recommend.
It just seems like an API deficiency we can fix without having
to touch the filesystem.

Cheers,
Carlos.


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