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
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_ptrblt::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