tzname 0: Eastern Standard Time
tzname 1: Eastern Daylight Time
which makes a little more sense
Peace, Jamie
Jamie LeTual wrote:
The following C code will get the "windowsified time zone (i.e. 'Atlantic Standard Time')
#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 =======================*/
