Re: [Boost-users] date_time: convert std::time_t to printable date in local time

From: Jeff Garland (jeff_at_[hidden])
Date: 2006-10-01 12:36:22

Andreas Ntaflos wrote:
> 
> Thank you both for your replies!
> 
> Constructing a posix_time_zone (CET with DST), a ptime from the 
> timestamp (time_t) using from_time_t() and then creating a 
> local_date_time object from the constructed posix_time_zone and the 
> ptime did exactly what I initially wanted.
> 
> I also considered the method shown in the Local to UTC Conversion 
> example which uses the c_local_adjustor, but it's apparently very 
> undocumented, which is probably why I didn't find it when searching 
> through the docs. This method seems to have the advantage that I do not 
> need to hard code the time zone into the program or read it from an 
> external database file. 

Yes, but it has other limitations.

> BTW: Why would it be dangerous to rely on the machine's time zone 
> settings? It seems to me that this would be a more robust and 
> convenient way of applying time zone adjustments. 

It's *dangerous* because it's basically impossible for a program to tell if 
the settings are correct.  On some OS's, average users can alter these 
settings and so your program may fail in unexpected ways if you expect the 
settings to be correct.

BTW, the various 'clock' classes already retrieve dates and times using the 
machine tz settings.  The real issue here is that there is no portable way to 
retrieve a timezone from the machine configuration that has all of the 
information to construct a timezone type.  That is, what *can* be determined 
is the current difference between UTC and local time, but not what the rules 
for daylight savings switchover, strings for DST versus non-DST, etc.  That's 
why the tz database stuff if provided as a separate configurable file that you 
can edit for your use.

> In fact, how would I be able to run my program in, say, NYC without 
> constructing a new time zone and recompiling it, should the company I 
> write it for ever decide to move there?

Your company would need to adopt a standard policy for machine configuration. 
  For example, setting an environment variable on all machines that contains a 
POSIX timezone string.  Note that if you are doing any sort of storage of 
dates/times in a database you really, really should use UTC if you have a 
system with sites in multiple timezones.

Jeff