Thread: [pywin32-bugs] [ pywin32-Bugs-1869586 ] win32timezone.GetSortedTimeZoneNames() doesn't work on NT4|
OLD project page for the Python extensions for Windows
Brought to you by:
mhammond
[pywin32-bugs] [ pywin32-Bugs-1869586 ]
win32timezone.GetSortedTimeZoneNames() doesn't work on NT4|6
From: SourceForge.net <no...@so...> - 2008-01-11 18:01:16
|
Bugs item #1869586, was opened at 2008-01-11 19:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1869586&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Antoine LECA (antoinel) Assigned to: Nobody/Anonymous (nobody) Summary: win32timezone.GetSortedTimeZoneNames() doesn't work on NT4|6 Initial Comment: win32timezone.GetSortedTimeZoneNames() uses the default value of win32timezone.GetIndexedTimeZoneNames()'s index_key, which is 'Index'. This entry was added to NT5 (Windows 2000) registry, and was not present before, i.e. in NT4 (even with all the patch applied). Furthermore, there is a important change between the two versions, in NT4 (and NT3 before) the key (e.g. 'Mountain Standard Time') was localized (so it ends as 'Montañas Hora estándar' on one box here, and as 'Heure d'hiver Montagnes Roch.' on another there.) So there is no easy way to add this index, or either to retrieve it from some other way. A workarounds would be to use the 'Display' (will display Ahead-of-GMT zones in order, then Behind-of-GMT zones in reverse order; not completely wrong but not smart); another (bad) workaround would be to use the 'TZI' field, but since it is stored little-endian, the resulting sort looks weird. The best I can find is to use the Bias field, which is the first bytes of the TZI fields; two bytes are enough to get an acceptable data; however the required change to GetIndexedTimeZoneRange is non-trivial, so it will have an impact on performance (even out of NT4). By the way, the 'Index' does not exist in Vista either (at least as it is shipped from Microsoft, I understand that some of the patches floating around to deal with the 2007 DST issue in the United States may have change this since the zones names do not vary much between NT5 and NT6) At first sight (source inspection), the current (1.78) CVS revision of win32timezone.py module carries the same problem, including for Vista... I'll try to do more test if I can. For Vista, a possible solution (=kludge) would be to use the indices of the resources in tzres.dll, which are monotically increasing following the same order as the Index field. Yes, it's a groß hack! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1869586&group_id=78018 |
[pywin32-bugs] [ pywin32-Bugs-1869586 ]
win32timezone.GetSortedTimeZoneNames() doesn't work on NT4|6
From: SourceForge.net <no...@so...> - 2008-10-13 19:42:57
|
Bugs item #1869586, was opened at 2008-01-11 13:01 Message generated for change (Settings changed) made by jaraco You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1869586&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None Status: Open >Resolution: Accepted Priority: 5 Private: No Submitted By: Antoine LECA (antoinel) >Assigned to: Jason R. Coombs (jaraco) Summary: win32timezone.GetSortedTimeZoneNames() doesn't work on NT4|6 Initial Comment: win32timezone.GetSortedTimeZoneNames() uses the default value of win32timezone.GetIndexedTimeZoneNames()'s index_key, which is 'Index'. This entry was added to NT5 (Windows 2000) registry, and was not present before, i.e. in NT4 (even with all the patch applied). Furthermore, there is a important change between the two versions, in NT4 (and NT3 before) the key (e.g. 'Mountain Standard Time') was localized (so it ends as 'Montaas Hora estndar' on one box here, and as 'Heure d'hiver Montagnes Roch.' on another there.) So there is no easy way to add this index, or either to retrieve it from some other way. A workarounds would be to use the 'Display' (will display Ahead-of-GMT zones in order, then Behind-of-GMT zones in reverse order; not completely wrong but not smart); another (bad) workaround would be to use the 'TZI' field, but since it is stored little-endian, the resulting sort looks weird. The best I can find is to use the Bias field, which is the first bytes of the TZI fields; two bytes are enough to get an acceptable data; however the required change to GetIndexedTimeZoneRange is non-trivial, so it will have an impact on performance (even out of NT4). By the way, the 'Index' does not exist in Vista either (at least as it is shipped from Microsoft, I understand that some of the patches floating around to deal with the 2007 DST issue in the United States may have change this since the zones names do not vary much between NT5 and NT6) At first sight (source inspection), the current (1.78) CVS revision of win32timezone.py module carries the same problem, including for Vista... I'll try to do more test if I can. For Vista, a possible solution (=kludge) would be to use the indices of the resources in tzres.dll, which are monotically increasing following the same order as the Index field. Yes, it's a gro hack! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1869586&group_id=78018 |
[pywin32-bugs] [ pywin32-Bugs-1869586 ]
win32timezone.GetSortedTimeZoneNames() doesn't work on NT4|6
From: SourceForge.net <no...@so...> - 2008-10-24 21:14:03
|
Bugs item #1869586, was opened at 2008-01-11 13:01 Message generated for change (Comment added) made by jaraco You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1869586&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Antoine LECA (antoinel) Assigned to: Jason R. Coombs (jaraco) Summary: win32timezone.GetSortedTimeZoneNames() doesn't work on NT4|6 Initial Comment: win32timezone.GetSortedTimeZoneNames() uses the default value of win32timezone.GetIndexedTimeZoneNames()'s index_key, which is 'Index'. This entry was added to NT5 (Windows 2000) registry, and was not present before, i.e. in NT4 (even with all the patch applied). Furthermore, there is a important change between the two versions, in NT4 (and NT3 before) the key (e.g. 'Mountain Standard Time') was localized (so it ends as 'Montañas Hora estándar' on one box here, and as 'Heure d'hiver Montagnes Roch.' on another there.) So there is no easy way to add this index, or either to retrieve it from some other way. A workarounds would be to use the 'Display' (will display Ahead-of-GMT zones in order, then Behind-of-GMT zones in reverse order; not completely wrong but not smart); another (bad) workaround would be to use the 'TZI' field, but since it is stored little-endian, the resulting sort looks weird. The best I can find is to use the Bias field, which is the first bytes of the TZI fields; two bytes are enough to get an acceptable data; however the required change to GetIndexedTimeZoneRange is non-trivial, so it will have an impact on performance (even out of NT4). By the way, the 'Index' does not exist in Vista either (at least as it is shipped from Microsoft, I understand that some of the patches floating around to deal with the 2007 DST issue in the United States may have change this since the zones names do not vary much between NT5 and NT6) At first sight (source inspection), the current (1.78) CVS revision of win32timezone.py module carries the same problem, including for Vista... I'll try to do more test if I can. For Vista, a possible solution (=kludge) would be to use the indices of the resources in tzres.dll, which are monotically increasing following the same order as the Index field. Yes, it's a groß hack! ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2008-10-24 17:14 Message: Antoine, I've modified the behavior to use the TimeZoneInfo.staticInfo.bias for the default sort order. I think this new version should be a drop-in replacement for most users. It works for me in Windows Vista. Can you test it in your NT4 environment? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1869586&group_id=78018 |
[pywin32-bugs] [ pywin32-Bugs-1869586 ]
win32timezone.GetSortedTimeZoneNames() doesn't work on NT4|6
From: SourceForge.net <no...@so...> - 2008-11-06 20:00:48
|
Bugs item #1869586, was opened at 2008-01-11 19:01 Message generated for change (Comment added) made by antoinel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1869586&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Antoine LECA (antoinel) Assigned to: Jason R. Coombs (jaraco) Summary: win32timezone.GetSortedTimeZoneNames() doesn't work on NT4|6 Initial Comment: win32timezone.GetSortedTimeZoneNames() uses the default value of win32timezone.GetIndexedTimeZoneNames()'s index_key, which is 'Index'. This entry was added to NT5 (Windows 2000) registry, and was not present before, i.e. in NT4 (even with all the patch applied). Furthermore, there is a important change between the two versions, in NT4 (and NT3 before) the key (e.g. 'Mountain Standard Time') was localized (so it ends as 'Montañas Hora estándar' on one box here, and as 'Heure d'hiver Montagnes Roch.' on another there.) So there is no easy way to add this index, or either to retrieve it from some other way. A workarounds would be to use the 'Display' (will display Ahead-of-GMT zones in order, then Behind-of-GMT zones in reverse order; not completely wrong but not smart); another (bad) workaround would be to use the 'TZI' field, but since it is stored little-endian, the resulting sort looks weird. The best I can find is to use the Bias field, which is the first bytes of the TZI fields; two bytes are enough to get an acceptable data; however the required change to GetIndexedTimeZoneRange is non-trivial, so it will have an impact on performance (even out of NT4). By the way, the 'Index' does not exist in Vista either (at least as it is shipped from Microsoft, I understand that some of the patches floating around to deal with the 2007 DST issue in the United States may have change this since the zones names do not vary much between NT5 and NT6) At first sight (source inspection), the current (1.78) CVS revision of win32timezone.py module carries the same problem, including for Vista... I'll try to do more test if I can. For Vista, a possible solution (=kludge) would be to use the indices of the resources in tzres.dll, which are monotically increasing following the same order as the Index field. Yes, it's a groß hack! ---------------------------------------------------------------------- >Comment By: Antoine LECA (antoinel) Date: 2008-11-06 21:00 Message: OK, great job Jason, now it works perfectly on this great 'ld Spanish NT4 server I am still using (but we are talking about retirement). Of course now I have to deal with the fact the strings I got on this box are Unicode'd, with plently of beautiful accentuated vowels :-), but that is MY problem. Thanks again, and hope it will fly many years. Notes for the report: this server has pywin32 v.210 running on Python 2.5. I just dropped the win32timezone.py inside win32lib, masked the .py[oc] and it works OK. ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2008-10-24 23:14 Message: Antoine, I've modified the behavior to use the TimeZoneInfo.staticInfo.bias for the default sort order. I think this new version should be a drop-in replacement for most users. It works for me in Windows Vista. Can you test it in your NT4 environment? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1869586&group_id=78018 |
[pywin32-bugs] [ pywin32-Bugs-1869586 ]
win32timezone.GetSortedTimeZoneNames() doesn't work on NT4|6
From: SourceForge.net <no...@so...> - 2008-11-06 20:40:44
|
Bugs item #1869586, was opened at 2008-01-11 13:01 Message generated for change (Comment added) made by jaraco You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1869586&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Antoine LECA (antoinel) Assigned to: Jason R. Coombs (jaraco) Summary: win32timezone.GetSortedTimeZoneNames() doesn't work on NT4|6 Initial Comment: win32timezone.GetSortedTimeZoneNames() uses the default value of win32timezone.GetIndexedTimeZoneNames()'s index_key, which is 'Index'. This entry was added to NT5 (Windows 2000) registry, and was not present before, i.e. in NT4 (even with all the patch applied). Furthermore, there is a important change between the two versions, in NT4 (and NT3 before) the key (e.g. 'Mountain Standard Time') was localized (so it ends as 'Montañas Hora estándar' on one box here, and as 'Heure d'hiver Montagnes Roch.' on another there.) So there is no easy way to add this index, or either to retrieve it from some other way. A workarounds would be to use the 'Display' (will display Ahead-of-GMT zones in order, then Behind-of-GMT zones in reverse order; not completely wrong but not smart); another (bad) workaround would be to use the 'TZI' field, but since it is stored little-endian, the resulting sort looks weird. The best I can find is to use the Bias field, which is the first bytes of the TZI fields; two bytes are enough to get an acceptable data; however the required change to GetIndexedTimeZoneRange is non-trivial, so it will have an impact on performance (even out of NT4). By the way, the 'Index' does not exist in Vista either (at least as it is shipped from Microsoft, I understand that some of the patches floating around to deal with the 2007 DST issue in the United States may have change this since the zones names do not vary much between NT5 and NT6) At first sight (source inspection), the current (1.78) CVS revision of win32timezone.py module carries the same problem, including for Vista... I'll try to do more test if I can. For Vista, a possible solution (=kludge) would be to use the indices of the resources in tzres.dll, which are monotically increasing following the same order as the Index field. Yes, it's a groß hack! ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2008-11-06 15:40 Message: Thanks to Antoine for testing the changes. Mark, can you check in the changes? I've included two patches, the first which just cleans up whitespace. The second addresses the issue in this bug and deprecates several functions (while attempting to maintain backward compatibility). You're welcome to just apply changes together, but it will be a cleaner CVS history if the patches are committed separately. ---------------------------------------------------------------------- Comment By: Antoine LECA (antoinel) Date: 2008-11-06 15:00 Message: OK, great job Jason, now it works perfectly on this great 'ld Spanish NT4 server I am still using (but we are talking about retirement). Of course now I have to deal with the fact the strings I got on this box are Unicode'd, with plently of beautiful accentuated vowels :-), but that is MY problem. Thanks again, and hope it will fly many years. Notes for the report: this server has pywin32 v.210 running on Python 2.5. I just dropped the win32timezone.py inside win32lib, masked the .py[oc] and it works OK. ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2008-10-24 17:14 Message: Antoine, I've modified the behavior to use the TimeZoneInfo.staticInfo.bias for the default sort order. I think this new version should be a drop-in replacement for most users. It works for me in Windows Vista. Can you test it in your NT4 environment? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1869586&group_id=78018 |
[pywin32-bugs] [ pywin32-Bugs-1869586 ]
win32timezone.GetSortedTimeZoneNames() doesn't work on NT4|6
From: SourceForge.net <no...@so...> - 2008-11-06 20:40:57
|
Bugs item #1869586, was opened at 2008-01-11 13:01 Message generated for change (Settings changed) made by jaraco You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1869586&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Antoine LECA (antoinel) >Assigned to: Mark Hammond (mhammond) Summary: win32timezone.GetSortedTimeZoneNames() doesn't work on NT4|6 Initial Comment: win32timezone.GetSortedTimeZoneNames() uses the default value of win32timezone.GetIndexedTimeZoneNames()'s index_key, which is 'Index'. This entry was added to NT5 (Windows 2000) registry, and was not present before, i.e. in NT4 (even with all the patch applied). Furthermore, there is a important change between the two versions, in NT4 (and NT3 before) the key (e.g. 'Mountain Standard Time') was localized (so it ends as 'Montañas Hora estándar' on one box here, and as 'Heure d'hiver Montagnes Roch.' on another there.) So there is no easy way to add this index, or either to retrieve it from some other way. A workarounds would be to use the 'Display' (will display Ahead-of-GMT zones in order, then Behind-of-GMT zones in reverse order; not completely wrong but not smart); another (bad) workaround would be to use the 'TZI' field, but since it is stored little-endian, the resulting sort looks weird. The best I can find is to use the Bias field, which is the first bytes of the TZI fields; two bytes are enough to get an acceptable data; however the required change to GetIndexedTimeZoneRange is non-trivial, so it will have an impact on performance (even out of NT4). By the way, the 'Index' does not exist in Vista either (at least as it is shipped from Microsoft, I understand that some of the patches floating around to deal with the 2007 DST issue in the United States may have change this since the zones names do not vary much between NT5 and NT6) At first sight (source inspection), the current (1.78) CVS revision of win32timezone.py module carries the same problem, including for Vista... I'll try to do more test if I can. For Vista, a possible solution (=kludge) would be to use the indices of the resources in tzres.dll, which are monotically increasing following the same order as the Index field. Yes, it's a groß hack! ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2008-11-06 15:40 Message: Thanks to Antoine for testing the changes. Mark, can you check in the changes? I've included two patches, the first which just cleans up whitespace. The second addresses the issue in this bug and deprecates several functions (while attempting to maintain backward compatibility). You're welcome to just apply changes together, but it will be a cleaner CVS history if the patches are committed separately. ---------------------------------------------------------------------- Comment By: Antoine LECA (antoinel) Date: 2008-11-06 15:00 Message: OK, great job Jason, now it works perfectly on this great 'ld Spanish NT4 server I am still using (but we are talking about retirement). Of course now I have to deal with the fact the strings I got on this box are Unicode'd, with plently of beautiful accentuated vowels :-), but that is MY problem. Thanks again, and hope it will fly many years. Notes for the report: this server has pywin32 v.210 running on Python 2.5. I just dropped the win32timezone.py inside win32lib, masked the .py[oc] and it works OK. ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2008-10-24 17:14 Message: Antoine, I've modified the behavior to use the TimeZoneInfo.staticInfo.bias for the default sort order. I think this new version should be a drop-in replacement for most users. It works for me in Windows Vista. Can you test it in your NT4 environment? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1869586&group_id=78018 |
[pywin32-bugs] [ pywin32-Bugs-1869586 ]
win32timezone.GetSortedTimeZoneNames() doesn't work on NT4|6
From: SourceForge.net <no...@so...> - 2008-11-11 00:02:56
|
Bugs item #1869586, was opened at 2008-01-12 05:01 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1869586&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Antoine LECA (antoinel) Assigned to: Mark Hammond (mhammond) Summary: win32timezone.GetSortedTimeZoneNames() doesn't work on NT4|6 Initial Comment: win32timezone.GetSortedTimeZoneNames() uses the default value of win32timezone.GetIndexedTimeZoneNames()'s index_key, which is 'Index'. This entry was added to NT5 (Windows 2000) registry, and was not present before, i.e. in NT4 (even with all the patch applied). Furthermore, there is a important change between the two versions, in NT4 (and NT3 before) the key (e.g. 'Mountain Standard Time') was localized (so it ends as 'Montañas Hora estándar' on one box here, and as 'Heure d'hiver Montagnes Roch.' on another there.) So there is no easy way to add this index, or either to retrieve it from some other way. A workarounds would be to use the 'Display' (will display Ahead-of-GMT zones in order, then Behind-of-GMT zones in reverse order; not completely wrong but not smart); another (bad) workaround would be to use the 'TZI' field, but since it is stored little-endian, the resulting sort looks weird. The best I can find is to use the Bias field, which is the first bytes of the TZI fields; two bytes are enough to get an acceptable data; however the required change to GetIndexedTimeZoneRange is non-trivial, so it will have an impact on performance (even out of NT4). By the way, the 'Index' does not exist in Vista either (at least as it is shipped from Microsoft, I understand that some of the patches floating around to deal with the 2007 DST issue in the United States may have change this since the zones names do not vary much between NT5 and NT6) At first sight (source inspection), the current (1.78) CVS revision of win32timezone.py module carries the same problem, including for Vista... I'll try to do more test if I can. For Vista, a possible solution (=kludge) would be to use the indices of the resources in tzres.dll, which are monotically increasing following the same order as the Index field. Yes, it's a groß hack! ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2008-11-11 11:02 Message: Thanks guys! Checking in win32timezone.py; new revision: 1.10; previous revision: 1.9 Checking in win32timezone.py; new revision: 1.11; previous revision: 1.10 ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2008-11-07 07:40 Message: Thanks to Antoine for testing the changes. Mark, can you check in the changes? I've included two patches, the first which just cleans up whitespace. The second addresses the issue in this bug and deprecates several functions (while attempting to maintain backward compatibility). You're welcome to just apply changes together, but it will be a cleaner CVS history if the patches are committed separately. ---------------------------------------------------------------------- Comment By: Antoine LECA (antoinel) Date: 2008-11-07 07:00 Message: OK, great job Jason, now it works perfectly on this great 'ld Spanish NT4 server I am still using (but we are talking about retirement). Of course now I have to deal with the fact the strings I got on this box are Unicode'd, with plently of beautiful accentuated vowels :-), but that is MY problem. Thanks again, and hope it will fly many years. Notes for the report: this server has pywin32 v.210 running on Python 2.5. I just dropped the win32timezone.py inside win32lib, masked the .py[oc] and it works OK. ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2008-10-25 08:14 Message: Antoine, I've modified the behavior to use the TimeZoneInfo.staticInfo.bias for the default sort order. I think this new version should be a drop-in replacement for most users. It works for me in Windows Vista. Can you test it in your NT4 environment? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1869586&group_id=78018 |