> > Please see the
> > result of 2nd est5edt, where _dstbias is zero and _daylight is
> > non-zero, which causes the issue.  I guess the first -3600 is probably
> > initial value because Microsoft says that initial values are for
> > "PST8PDT".
> 
> I can understand this in your case, since your timezone doesn't
> specify DST.  Can you show me what the GetTimeZoneInformation API
> returns on your system with your default timezone?

I tried with following code.

#include <stdio.h>
#include <windows.h>

void printSYSTEMTIME (const char *name, LPSYSTEMTIME time) {
  printf("%s is %ld, %ld, %ld, %ld, %ld, %ld, %ld, %ld\n",
	 name, time->wYear, time->wMonth, time->wDayOfWeek,
	 time->wDay, time->wHour, time->wMinute, time->wSecond,
	 time->wMilliseconds);
}

int main (int argc, wchar_t* argv[]) {
  TIME_ZONE_INFORMATION timezone;

  DWORD result = GetTimeZoneInformation(&timezone);

  printf ("Return code is %d\n", result);
  printf ("Bias is %ld\n", timezone.Bias);
  wprintf (L"StandardName is %s\n", timezone.StandardName);
  printSYSTEMTIME("StandardDate", &timezone.StandardDate);
  printf ("StandardBias is %ld\n", timezone.StandardBias);
  wprintf (L"DaylightName is %s\n", timezone.DaylightName);
  printSYSTEMTIME("StandardDate", &timezone.DaylightDate);
  printf ("DaylightBias is %ld\n", timezone.DaylightBias);

  return 0;
}

result:
Return code is 0
Bias is -540
StandardName is 東京 (in utf-16-le)
StandardDate is 0, 0, 0, 0, 0, 0, 0, 0
StandardBias is 0
DaylightName is 東京 (in utf-16-le)
StandardDate is 0, 0, 0, 0, 0, 0, 0, 0
DaylightBias is 0

result on Eastern Standard Time:
Return code is 2
Bias is 300
StandardName is 東部標準時 (in utf-16-le)
StandardDate is 0, 11, 0, 1, 2, 0, 0, 0
StandardBias is 0
DaylightName is 東部夏時間 (in utf-16-le)
StandardDate is 0, 3, 0, 2, 2, 0, 0, 0
DaylightBias is -60

> > > Sorry, I don't think I understand: AFAIU, _dstbias can legitimately be
> > > zero in timezones that don't support DST.  If that is true, correcting
> > > a zero-valued _dstbias to 1 hour will cause problems, no?
> > > should also look at the value of _daylight, and only do the _dstbias
> > > correction of _daylight is zero (i.e. no DST in this timezone)?  Or
> > > what am I missing?
> > 
> > I agree with you that _dstbias should be zero when _daylight is zero.
> > However, as I wrote above, _dstbias should not be used when _daylight
> > is zero.  My emacs has set TZ to JST-9 long time and _dstbias has been
> > -3600 according to my test.  It has no problem till now.  So I removed
> > _daylight value check before posting the patch, but If you mind,
> > correcting _dstbias only when _daylight is *NON-ZERO* (not _daylight
> > is zero!) should be okay.
> 
> See above: I think I changed my mind, and we should set _dstbias
> according to the actual value of TZ, and only if TZ is indeed set
> (because I think if TZ is not set, MSVCRT gets the correct value from
> GetTimeZoneInformation).  Can you try that and see if it improves the
> current situation?

Please see attached patch.  I think we don't need to re-parse TZ value
because it is already parsed by tzset and the result is set to
_daylight variable.  In addition, I noticed there is a code that calls
tztest and needs the same workaoround on Windows in lib/time_rz.c,
however I don't know how to apply the change only on Windows.  Please
see the second patch.


--
Kazuhiro Ito