#include <stdio.h> #include <time.h>
int main(int argc, char **argv)
{
_tzset();
printf("tzname 0: %s\n",_tzname[0]);
printf("tzname 1: %s\n",_tzname[1]);}
You need the call to _tzset() to initialize the values in _tzname[].
The msdn doc says that _tzname[0] is derived from the TZ environment variable, and that _tzname[1] defaults to PDT, and if the DST isn't set, its an empty string.
When I ran that just now, both contained "Atlantic Standard Time" (without the quotes).
Also, after calling _tzset(), two other globals are populated,
int _daylight = 0 || 1 (like isDst)
long _timezone = difference in seconds between coordinated universal time and localtime (defaults to 28,000; presumably thats PDT).
That should be easy enough to wrap, although I only started to get interested in DateTime, and haven't poked any code yet. Looking forward to it however, I think a project like this is long overdue.
Hope this helps, Peace, Jamie
Dave Rolsky wrote:
On Wed, 4 Feb 2004, Ilya A. Tereshchenko wrote:
my @t = gmtime; my $local = Time::Local::timelocal(@t); my $gm = Time::Local::timegm(@t);
return DateTime::TimeZone::OffsetOnly->new ( offset => offset_as_string( $gm - $local ) );
What was the reason of cutting off that method? Yes, there are several new
The problem with this is that it doesn't really get a valid timezone, but instead gets the current offset from UTC. If this code runs in a timezone that has daylight saving changes, then it will not be all that accurate.
All the new methods for determining the local time zone are more likely to get something useful like "Europe/Paris", which is a real time zone.
only under UNIX systems. Unfortunately, my script should work under Windows and, therefore, I have lost a chance to determine local timezone. The only way left under Windows is to use environment variable, but this method scarcely applicable for me too: the script will be used by customer and I can't guarantee that TZ variable always will be set properly. For the
I know that Windows stores a real time zone _somewhere_, and there's got to be a way to get that information. A patch to do so would be welcome. Even better would be a patch with tests that are known to pass on Win32.
But the old "get the current offset" approach really was fundamentally broken, and I'm not willing to put it back in.
-dave
/*======================= House Absolute Consulting www.houseabsolute.com =======================*/
