Roger Olson wrote:
RCS file: /home/wine/wine/dlls/ntdll/time.c,v retrieving revision 1.51 diff -u -u -r1.51 time.c --- dlls/ntdll/time.c 22 Oct 2004 19:54:17 -0000 1.51 +++ dlls/ntdll/time.c 31 Oct 2004 21:18:46 -0000 @@ -105,6 +105,9 @@ {"AKDT", {'A','l','a','s','k','a','n',' ','S','t','a','n','d','a','r','d',' ','T', 'i','m','e','\0'}, 480, 1},
- {"PST",
- {'P','a','c','i','f','i','c',' ','S','t','a','n','d','a','r','d',' ','T',
'i','m','e','\0'}, 480, 0},
Hmm... I don't know if anything actually uses the names, but I doubt these are right. PDT would normally be referred to as Pacific Daylight Time. Any chance of getting you to add some tests for these?
I agree that PDT should say "Pacific Daylight Time" but whoever wrote this section refered to both ..DT and ..ST as "Standard Time" for some good reason.I assumed so I followed convention. It came up in an app I was running as a fixme since we switched to std time today and is used by TIME_GetTZAsStr(). If it appears beneficial, I'll be happy to change all the ..DT references to "Daylight Time" and resubmit.
Duane Clark on Sunday, October 31, 2004 2:34 PM wrote:
Roger Olson wrote:
RCS file: /home/wine/wine/dlls/ntdll/time.c,v retrieving revision 1.51 diff -u -u -r1.51 time.c --- dlls/ntdll/time.c 22 Oct 2004 19:54:17 -0000 1.51 +++ dlls/ntdll/time.c 31 Oct 2004 21:18:46 -0000 @@ -105,6 +105,9 @@ {"AKDT", {'A','l','a','s','k','a','n',' ','S','t','a','n','d','a','r','d','
','T',
'i','m','e','\0'}, 480, 1},
- {"PST",
- {'P','a','c','i','f','i','c',' ','S','t','a','n','d','a','r','d','
','T',
'i','m','e','\0'}, 480, 0},
','T',
'i','m','e','\0'}, 420, 1},Hmm... I don't know if anything actually uses the names, but I doubt these are right. PDT would normally be referred to as Pacific Daylight Time. Any chance of getting you to add some tests for these?
Roger wrote:
I agree that PDT should say "Pacific Daylight Time" but whoever wrote this section refered to both ..DT and ..ST as "Standard Time" for some good reason.I assumed so I followed convention. It came up in an app I was running as a fixme since we switched to std time today and is used by TIME_GetTZAsStr(). If it appears beneficial, I'll be happy to change all the ..DT references to "Daylight Time" and resubmit.
Not quite every place; MEST says daylight. It appears to me that the only place this is used is the function TIME_GetTZAsStr(), which appears to only be used in RtlQueryTimeZoneInformation(). So the question would be, what does that function return on Windows (and perhaps, does any program care).
On Sun, 31 Oct 2004 16:29:59 -0800, you wrote:
Roger wrote:
I agree that PDT should say "Pacific Daylight Time" but whoever wrote this section refered to both ..DT and ..ST as "Standard Time" for some good reason.I assumed so I followed convention. It came up in an app I was running as a fixme since we switched to std time today and is used by TIME_GetTZAsStr(). If it appears beneficial, I'll be happy to change all the ..DT references to "Daylight Time" and resubmit.
Not quite every place; MEST says daylight. It appears to me that the only place this is used is the function TIME_GetTZAsStr(), which appears to only be used in RtlQueryTimeZoneInformation().
Yes, it fills in the field "StandardName" of the TimeZoneInformation structure. When it uses TIME_GetTZAsStr, the returned Info pretends this zone has no transitions (but adjusts the Bias at the right time). So it is correct that this table should only hold standard times. It is also a broken way of doing things, these time abbreviations are not unique.
So the question would be, what does that function return on Windows
It does what RtlQueryTimeZoneInformation does if TIME_GetTimeZoneInfoFromReg returns successfull.
(and perhaps, does any program care).
On windows they are localized, so I don't think an exact string match matters.
Rein.
"Duane" == Duane Clark dclark@akamail.com writes:
Duane> Roger wrote: >> I agree that PDT should say "Pacific Daylight Time" but whoever wrote >> this section refered to both ..DT and ..ST as "Standard Time" for >> some good reason.I assumed so I followed convention. It came up in >> an app I was running as a fixme since we switched to std time today >> and is used by TIME_GetTZAsStr(). If it appears beneficial, I'll be >> happy to change all the ..DT references to "Daylight Time" and >> resubmit. >>
Duane> Not quite every place; MEST says daylight. It appears to me that Duane> the only place this is used is the function TIME_GetTZAsStr(), Duane> which appears to only be used in Duane> RtlQueryTimeZoneInformation(). So the question would be, what Duane> does that function return on Windows (and perhaps, does any Duane> program care).
These timezione names are a mess, both under windows and wine... On windows they depend on the language version.
What I have seen so long:
Xilinx Webupdate depends on the string returned to be non-Null.
Bye
-
Duane Clark -
Rein Klazes -
Roger -
Uwe Bonnes