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