Unix Programming - Timezone conversions with zoneinfo

Author

Timezone conversions with zoneinfo

Ken Bloom

2006-06-29, 9:59 pm

I'm trying to do timezone conversions from UTC using the zoneinfo
database, by using the following routine:

date convert_to_tz(date theday, double thetime, std::string timezone){
struct tm tm;
time_t timenum;

//mktime has the side effect of normalizing tm
tm.tm_min=tm.tm_hour=0;
tm.tm_sec=static_cast<int>(thetime*60*60);
tm.tm_mon=theday.month()-1;
tm.tm_mday=theday.day();
tm.tm_year=theday.year()-1900;

//Get timenum for the UTC time.
setenv("TZ","UTC",1);
tzset();
timenum=mktime(&tm);

//Convert back to the requested local timezone
setenv("TZ",timezone.c_str(),1);
tzset();
localtime_r(&timenum,&tm);

//return a value
date returnDate(tm.tm_mon+1,tm.tm_mday,tm.tm_year+1900);
returnDate.hour(tm.tm_hour);
returnDate.min(tm.tm_min);
return returnDate;
}

date is a class I wrote for handling dates. thetime is a double
representing a fractional number of hours. (I've been using
approximately 10 and 25 for this number)

The code behaves correctly for the DST change between 4/1/2006 and
4/2/2006, but the upcoming DST change between 3/10/2007 and 3/11/2007
is being encountered a day early (i.e. between 3/9/2007 and
3/10/2007).

However the date(1) gets the time change right.

[bloom@little-cat-a zmanim-simpletz]$ date -d '3/10/2007 10:00pm'
Sat Mar 10 22:00:00 EST 2007
[bloom@little-cat-a zmanim-simpletz]$ date -d '3/11/2007 10:00pm'
Sun Mar 11 22:00:00 EDT 2007

Any idea what's wrong with my code? Is it my code at all? Is there
someone appropriate to ask whether it's a system bug?

--Ken Bloom

--
I usually have a GPG digital signature included as an attachment.
See http://www.gnupg.org/ for info about these digital signatures.

Ken Bloom

2006-06-29, 9:59 pm

Ken Bloom <kbloom@gmail.com> wrote:
> I'm trying to do timezone conversions from UTC using the zoneinfo
> database, by using the following routine:
>
> date convert_to_tz(date theday, double thetime, std::string timezone){
> struct tm tm;
> time_t timenum;
>
> //mktime has the side effect of normalizing tm
> tm.tm_min=tm.tm_hour=0;
> tm.tm_sec=static_cast<int>(thetime*60*60);
> tm.tm_mon=theday.month()-1;
> tm.tm_mday=theday.day();
> tm.tm_year=theday.year()-1900;
>
> //Get timenum for the UTC time.
> setenv("TZ","UTC",1);
> tzset();
> timenum=mktime(&tm);
>
> //Convert back to the requested local timezone
> setenv("TZ",timezone.c_str(),1);
> tzset();
> localtime_r(&timenum,&tm);
>
> //return a value
> date returnDate(tm.tm_mon+1,tm.tm_mday,tm.tm_year+1900);
> returnDate.hour(tm.tm_hour);
> returnDate.min(tm.tm_min);
> return returnDate;
> }
>
> date is a class I wrote for handling dates. thetime is a double
> representing a fractional number of hours. (I've been using
> approximately 10 and 25 for this number)
>
> The code behaves correctly for the DST change between 4/1/2006 and
> 4/2/2006, but the upcoming DST change between 3/10/2007 and 3/11/2007
> is being encountered a day early (i.e. between 3/9/2007 and
> 3/10/2007).
>
> However the date(1) gets the time change right.
>
> [bloom@little-cat-a zmanim-simpletz]$ date -d '3/10/2007 10:00pm'
> Sat Mar 10 22:00:00 EST 2007
> [bloom@little-cat-a zmanim-simpletz]$ date -d '3/11/2007 10:00pm'
> Sun Mar 11 22:00:00 EDT 2007
>
> Any idea what's wrong with my code? Is it my code at all? Is there
> someone appropriate to ask whether it's a system bug?

Fixed the bug. It wasn't the timezone conversion. It was the number
thetime I was feeding the timezone conversion. It was from a
sunrise/sunset calculation which was giving screwy numbers in March,
but sane ones in April.

--Ken

--
I usually have a GPG digital signature included as an attachment.
See http://www.gnupg.org/ for info about these digital signatures.

Sponsored Links