This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: RFC [PATCH] BZ#1077902: New API gettimezone
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Paul Eggert <eggert at cs dot ucla dot edu>, Rich Felker <dalias at aerifal dot cx>, P J P <pj dot pandit at yahoo dot co dot in>
- Cc: "libc-help at sourceware dot org" <libc-help at sourceware dot org>
- Date: Fri, 04 Apr 2014 01:46:07 -0400
- Subject: Re: RFC [PATCH] BZ#1077902: New API gettimezone
- Authentication-results: sourceware.org; auth=none
- References: <1396499286 dot 85118 dot YahooMailNeo at web192405 dot mail dot sg3 dot yahoo dot com> <533CF5E8 dot 9010009 at cs dot ucla dot edu> <1396518081 dot 53447 dot YahooMailNeo at web192403 dot mail dot sg3 dot yahoo dot com> <533D73DF dot 1040009 at cs dot ucla dot edu> <1396546236 dot 69027 dot YahooMailNeo at web192401 dot mail dot sg3 dot yahoo dot com> <20140403194040 dot GG26358 at brightrain dot aerifal dot cx> <533DD86D dot 10908 at redhat dot com> <533DE5CA dot 5040905 at cs dot ucla dot edu> <533E16A5 dot 5030701 at redhat dot com> <533E1AB7 dot 5090804 at cs dot ucla dot edu>
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.