Re: [Boost-users] [Date_Time] Posix Time Zone offset question

From: Jacob Anawalt (jacob_at_[hidden])
Date: 2006-10-30 13:24:42

Jeff Garland wrote:
> 
> So, after staring at this spec for awhile, it looks to me that this is a major 
> bug in posix timezone :-( For whatever reason, posix has the utc offset 
> definitions inverted from the way it actually is...so you always have to 
> invert the sign of the offset to get the actual utc offset.
> 

I thought this was weird too, but that's how they spec'd it.

> To be 100% sure, I'll need a bit more info. What OS are you using, what 
> timezone are you in, and what is TZ set to?  Assuming it's unix, what do 
> 'date' and 'date -u' give you?
> 

Debian 3.1 (GNU/Linux)
America/Denver
MST7MDT,M4.1.0,M10,5.0 (for 1987-2006)

$ date
Mon Oct 30 10:36:59 MST 2006
$ date -u
Mon Oct 30 17:37:03 UTC 2006
$ TZ=MST7MDT,M4.1.0,M10,5.0 date
Mon Oct 30 10:37:24 MST 2006
$ date --version
date (coreutils) 5.2.1
Written by David MacKenzie.

Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

> And then what I assume you are doing exactly in date-time.  Based on the first 
> email you sent I imagine it's something like:
> 
> shared_ptr<time_zone> tz(new posix_time_zone("MST7MDT,M4.1.0,M10.5.0"));
> local_date_time ldt1 = local_sec_clock::local_time(tz);
> 

Pretty much. This is some of my test code.

namespace blt = boost::local_time;
namespace bpt = boost::posix_time;

bpt::ptime pt = bpt::second_clock::universal_time();
boost::shared_ptr<blt::time_zone_base> zone(
         new blt::posix_time_zone("MST7MDT,M4.1.0,M10.5.0"));

blt::local_date_time ldt1(pt,zone);

After familiarizing myself with the Local Time classes, my goal is to 
make a little wall time conversion program. Using the local_date_time 
class objects seems much cleaner and thread safe than messing with tzset 
(and thus the program's idea of the current TZ, tzname, timezone and 
daylight.)

My TZ variable is normally empty and glibc looks at it's notion of the 
default zone in that case using the /usr/share/zoneinfo data. For now 
that's OK. The POSIX.1 spec says that if TZ is empty or starts with a 
colon, it's interpretation is implementation specific. My program's 
documented interpretation will be to default to UTC, so I'll have to run 
it with the right target TZ set if I want a different wall clock than UTC.

Thank you for looking at this,
-- 
Jacob