Hello,

I'm trying to devise a portable function for retrtieving timezone
information. The following is what I have so far:

#if defined(__FreeBSD__)
#else
extern int daylight;
extern long timezone;
#endif

int
time_get_tzdata(int *offset, int *is_dst)
{
#if defined(__FreeBSD__)
struct tm ltm, gtm;
time_t lt, gt;

lt = time(NULL);
localtime_r(<, <m);
*is_dst = ltm.tm_isdst;
gmtime_r(<, >m);
lt = mktime(<m);
gt = mktime(>m);
*offset = gt - lt;
#else
tzset();
*offset = timezone;
*is_dst = daylight;
#endif

return 0;
}

My question is simply - is there a better way to do this?

I know systems have this information readily available so I'm a little
annoyed that I have to jump through hoops to get to it.

Thanks,
Mike

[ Post a follow-up to this message ]

On Wed, 18 Jul 2007 11:42:09 -0400, Michael B Allen wrote:

> Hello,
>
> I'm trying to devise a portable function for retrtieving timezone
> information. The following is what I have so far:
>
> #if defined(__FreeBSD__)
> #else
> extern int daylight;
> extern long timezone;
> #endif
>
> int
> time_get_tzdata(int *offset, int *is_dst) {
> #if defined(__FreeBSD__)
>     struct tm ltm, gtm;
>     time_t lt, gt;
>
>     lt = time(NULL);
>     localtime_r(<, <m);
>     *is_dst = ltm.tm_isdst;
>     gmtime_r(<, >m);
>     lt = mktime(<m);
>     gt = mktime(>m);
>     *offset = gt - lt;
> #else
>     tzset();
>     *offset = timezone;
>     *is_dst = daylight;
> #endif
>
>     return 0;
> }

From man tzset:

NOTES
Note  that the variable daylight does not indicate that daylight saving
time applies right now. It used to give the number  of  some  algorithm
(see the variable tz_dsttime in gettimeofday(2)).  It has been obsolete
for many years but is required by SUSv2.

> My question is simply - is there a better way to do this?

Most applications that want more time info. than SuS provides go
directly to parsing the tzfile data (man tzfile on Linux). Although
that might be overkill for your situation (although I'm interested in
what you need just the above for).

--
James Antill -- james@and.org
C String APIs use too much memory? ustr: length, ref count, size and
read-only/fixed. Ave. 44% overhead over strdup(), for 0-20B strings
http://www.and.org/ustr/

[ Post a follow-up to this message ]

On Thu, 19 Jul 2007 16:00:12 -0000
James Antill <james-netnews@and.org> wrote:

> On Wed, 18 Jul 2007 11:42:09 -0400, Michael B Allen wrote:
> 
>
>  From man tzset:
>
> NOTES
>        Note  that the variable daylight does not indicate that daylight sa
ving
>        time applies right now. It used to give the number  of  some  algor
ithm
>        (see the variable tz_dsttime in gettimeofday(2)).  It has been obso
lete
>        for many years but is required by SUSv2.
> 
>
>  Most applications that want more time info. than SuS provides go
> directly to parsing the tzfile data (man tzfile on Linux). Although
> that might be overkill for your situation (although I'm interested in
> what you need just the above for).

Hi James,

Suffice it to say, it has to do with information in some network protocol
communication.

I guess I have no other choice but to read that incomprehensible man
page and then figure out how to do all of this in a portable way.

Man I wish there was an open portable lib that provided *good* APIs for
all the deficient stuff in *nix. Do *nix people think that theres a
problem or are they saying "there's nothing wrong, the problem is just
you buddy"?

Mike

[ Post a follow-up to this message ]

On Thu, 19 Jul 2007 14:22:34 -0400, Michael B Allen wrote:

> On Thu, 19 Jul 2007 16:00:12 -0000
> James Antill <james-netnews@and.org> wrote:
> 
>
> Hi James,
>
> Suffice it to say, it has to do with information in some network
> protocol communication.
>
> I guess I have no other choice but to read that incomprehensible man
> page and then figure out how to do all of this in a portable way.

Probably not .

> Man I wish there was an open portable lib that provided *good* APIs for
> all the deficient stuff in *nix. Do *nix people think that theres a
> problem or are they saying "there's nothing wrong, the problem is just
> you buddy"?

It's not the latter, at least IMO, although it may look that way. I'd
say there are a few problems:

1. The big problems are generally only really obvious/painful when you
want to write long running daemons, or shared libraries used by them,
in C.

2. In that solution space developers tend to be _very_ resistant to
external dependencies.

3. Writing those external deps. is often not rewarding, esp. when
noone uses (or helps/gives input on) what you make. This is even
more of a problem because making good library APIs is often
_much_[1] harder than doing a one off just for yourself.

4. If you make it getting something accepted by Fedora/Debian/*BSD
is probably more pain than any sane person wants.

5. Most of the developers have been doing it a long time, and know
most of the problems ... likely also knowing a workaround or two.

...my most recent experience of #2 and #5, was a "lead developer"
refusing to let me use a decent string API in a very security
sensitive C daemon ... I almost forgot it was 2007.

Anyway, back to your immediate problem. I know PostgreSQL has it's
own time handling via. the zoneinfo files, and I think evolution
does too. So if the documentation doesn't help as much as you'd like
you can always look at those for some inspiration/confirmation.


[1] As a minor data point, after spending a long time doing Vstr
I made the initial PoC of Ustr in about 5 hours (Ie. add, delete,
with minimal searching and comparison) ... at which point it was
usable to me.
Getting 1.0.0 took at least 25x that effort, and I'm getting my
first real set of outside contributions for 1.0.1.

--
James Antill -- james@and.org
C String APIs use too much memory? ustr: length, ref count, size and
read-only/fixed. Ave. 44% overhead over strdup(), for 0-20B strings
http://www.and.org/ustr/

[ Post a follow-up to this message ]