Обсуждение: Anyone want to update our Windows timezone map?
src/timezone/README saith
When there has been a new release of Windows (probably including Service Packs), the list of matching timezones need
tobe updated. Run the script in src/tools/win32tzlist.pl on a Windows machine running this new release and apply any
newtimezones that it detects. Never remove any mappings in case they are removed in Windows, since we still need to
matchproperly on the old version.
We have certainly not been doing that on a regular basis (as best I can
tell, no such changes have been made since 2010). Does anybody who uses
Windows want to deal with it? Or at least do it once so that our Windows
TZ info is less than 5 years out of date?
If we got this done in the next couple weeks, any resulting changes
could go out in 9.6rc1. Given that we've not done this routinely,
that seems like a better plan than having them first hit the field
in minor releases of stable branches.
regards, tom lane
On Tue, Aug 16, 2016 at 7:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > src/timezone/README saith > > When there has been a new release of Windows (probably including Service > Packs), the list of matching timezones need to be updated. Run the > script in src/tools/win32tzlist.pl on a Windows machine running this new > release and apply any new timezones that it detects. Never remove any > mappings in case they are removed in Windows, since we still need to > match properly on the old version. > > We have certainly not been doing that on a regular basis (as best I can > tell, no such changes have been made since 2010). Does anybody who uses > Windows want to deal with it? Or at least do it once so that our Windows > TZ info is less than 5 years out of date? By the way, I noticed that Unicode CLDR publishes this data set which seems to be the same sort of thing: http://www.unicode.org/cldr/charts/29/supplemental/zone_tzid.html Could that be a better source than dumping stuff from arbitrary Windows versions? -- Thomas Munro http://www.enterprisedb.com
Thomas Munro <thomas.munro@enterprisedb.com> writes: > On Tue, Aug 16, 2016 at 7:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> We have certainly not been doing that on a regular basis (as best I can >> tell, no such changes have been made since 2010). Does anybody who uses >> Windows want to deal with it? Or at least do it once so that our Windows >> TZ info is less than 5 years out of date? > By the way, I noticed that Unicode CLDR publishes this data set which > seems to be the same sort of thing: > http://www.unicode.org/cldr/charts/29/supplemental/zone_tzid.html > Could that be a better source than dumping stuff from arbitrary > Windows versions? Well, the point is that we need to recognize the timezone names that Windows actually uses. A list of strings that's more or less the same doesn't really cut it ... regards, tom lane
On Tue, Aug 16, 2016 at 4:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > We have certainly not been doing that on a regular basis (as best I can > tell, no such changes have been made since 2010). Does anybody who uses > Windows want to deal with it? Or at least do it once so that our Windows > TZ info is less than 5 years out of date? It would be a good idea to refresh that. > If we got this done in the next couple weeks, any resulting changes > could go out in 9.6rc1. Given that we've not done this routinely, > that seems like a better plan than having them first hit the field > in minor releases of stable branches. Agreed. I'll try to give it a shot in the next couple of days at worst. -- Michael
On Tue, Aug 16, 2016 at 9:14 AM, Michael Paquier <michael.paquier@gmail.com> wrote: > On Tue, Aug 16, 2016 at 4:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> We have certainly not been doing that on a regular basis (as best I can >> tell, no such changes have been made since 2010). Does anybody who uses >> Windows want to deal with it? Or at least do it once so that our Windows >> TZ info is less than 5 years out of date? > > It would be a good idea to refresh that. > >> If we got this done in the next couple weeks, any resulting changes >> could go out in 9.6rc1. Given that we've not done this routinely, >> that seems like a better plan than having them first hit the field >> in minor releases of stable branches. > > Agreed. I'll try to give it a shot in the next couple of days at worst. I ran the script on my Win10 station, and saw the attached output, which results in the patch attached once changes are applied. Results can be visibly quite different depending on the station used though, Win7 reports other things. Still my guess is that we'd want Win10 as a base. Note as well that the registry has switched to UTC instead of GMT. Thoughts? -- Michael
Вложения
On Tue, Aug 16, 2016 at 11:15 AM, Michael Paquier <michael.paquier@gmail.com> wrote:
On Tue, Aug 16, 2016 at 9:14 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Tue, Aug 16, 2016 at 4:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> We have certainly not been doing that on a regular basis (as best I can
>> tell, no such changes have been made since 2010). Does anybody who uses
>> Windows want to deal with it? Or at least do it once so that our Windows
>> TZ info is less than 5 years out of date?
>
> It would be a good idea to refresh that.
>
>> If we got this done in the next couple weeks, any resulting changes
>> could go out in 9.6rc1. Given that we've not done this routinely,
>> that seems like a better plan than having them first hit the field
>> in minor releases of stable branches.
>
> Agreed. I'll try to give it a shot in the next couple of days at worst.
I ran the script on my Win10 station, and saw the attached output,
which results in the patch attached once changes are applied. Results
can be visibly quite different depending on the station used though,
Win7 reports other things. Still my guess is that we'd want Win10 as a
base. Note as well that the registry has switched to UTC instead of
GMT. Thoughts?
I think what we want is basically the UNION ALL of all the different active versions. If we just use the definitions from Win10, we will map incorrectly on Win7. As long as they are not *conflicting*, we should just add them all.
The UTC->GMT switch is mostly just annoying as it only hits the comments, right? I think we just accept that change and do a once-over patch that changes all those things.
On Tue, Aug 16, 2016 at 6:22 PM, Magnus Hagander <magnus@hagander.net> wrote: > I think what we want is basically the UNION ALL of all the different active > versions. If we just use the definitions from Win10, we will map incorrectly > on Win7. As long as they are not *conflicting*, we should just add them all. I see, so that's why the script does not do any suggestions to remove any data. > The UTC->GMT switch is mostly just annoying as it only hits the comments, > right? I think we just accept that change and do a once-over patch that > changes all those things. OK, so after re-running that on my Win10 station and a newly updated Win7 station I am finishing with the attached that combines all the changes. -- Michael
Вложения
On Thu, Aug 18, 2016 at 7:06 AM, Michael Paquier <michael.paquier@gmail.com> wrote:
On Tue, Aug 16, 2016 at 6:22 PM, Magnus Hagander <magnus@hagander.net> wrote:
> I think what we want is basically the UNION ALL of all the different active
> versions. If we just use the definitions from Win10, we will map incorrectly
> on Win7. As long as they are not *conflicting*, we should just add them all.
I see, so that's why the script does not do any suggestions to remove any data.
Yup.
> The UTC->GMT switch is mostly just annoying as it only hits the comments,
> right? I think we just accept that change and do a once-over patch that
> changes all those things.
OK, so after re-running that on my Win10 station and a newly updated
Win7 station I am finishing with the attached that combines all the
changes.
Thanks, pushed for master and 9.6.
On Thu, Aug 18, 2016 at 7:38 PM, Magnus Hagander <magnus@hagander.net> wrote: > Thanks, pushed for master and 9.6. Cool. Thanks for the commit. -- Michael
Magnus Hagander <magnus@hagander.net> writes:
> On Thu, Aug 18, 2016 at 7:06 AM, Michael Paquier <michael.paquier@gmail.com>
> wrote:
>> OK, so after re-running that on my Win10 station and a newly updated
>> Win7 station I am finishing with the attached that combines all the
>> changes.
> Thanks, pushed for master and 9.6.
My thought was to push it in all branches --- that's what we do for
other timezone data updates.
regards, tom lane
On Thu, Aug 18, 2016 at 3:26 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> If we got this done in the next couple weeks, any resulting changes
> could go out in 9.6rc1. Given that we've not done this routinely,
> that seems like a better plan than having them first hit the field
Magnus Hagander <magnus@hagander.net> writes:
> On Thu, Aug 18, 2016 at 7:06 AM, Michael Paquier <michael.paquier@gmail.com>
> wrote:
>> OK, so after re-running that on my Win10 station and a newly updated
>> Win7 station I am finishing with the attached that combines all the
>> changes.
> Thanks, pushed for master and 9.6.
My thought was to push it in all branches --- that's what we do for
other timezone data updates.
Your initial comment was:
> If we got this done in the next couple weeks, any resulting changes
> could go out in 9.6rc1. Given that we've not done this routinely,
> that seems like a better plan than having them first hit the field
> in minor releases of stable branches.
I read that as we want it out in RC1 and make sure that works before we backpatch it to earlier branches.
Magnus Hagander <magnus@hagander.net> writes:
> On Thu, Aug 18, 2016 at 3:26 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> If we got this done in the next couple weeks, any resulting changes
>> could go out in 9.6rc1. Given that we've not done this routinely,
>> that seems like a better plan than having them first hit the field
>> in minor releases of stable branches.
> I read that as we want it out in RC1 and make sure that works before we
> backpatch it to earlier branches.
I think we might as well back-patch now so we don't forget to do so.
rc1 will give us a chance to discover any problems, but if there are
any, we'd back-patch those fixes too.
regards, tom lane
On Thu, Aug 18, 2016 at 3:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
> On Thu, Aug 18, 2016 at 3:26 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> If we got this done in the next couple weeks, any resulting changes
>> could go out in 9.6rc1. Given that we've not done this routinely,
>> that seems like a better plan than having them first hit the field
>> in minor releases of stable branches.
> I read that as we want it out in RC1 and make sure that works before we
> backpatch it to earlier branches.
I think we might as well back-patch now so we don't forget to do so.
rc1 will give us a chance to discover any problems, but if there are
any, we'd back-patch those fixes too.
OK, fair enough if you think so. I'll go ahead and do that right away.
On Thu, Aug 18, 2016 at 3:34 PM, Magnus Hagander <magnus@hagander.net> wrote:
On Thu, Aug 18, 2016 at 3:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:Magnus Hagander <magnus@hagander.net> writes:
> On Thu, Aug 18, 2016 at 3:26 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> If we got this done in the next couple weeks, any resulting changes
>> could go out in 9.6rc1. Given that we've not done this routinely,
>> that seems like a better plan than having them first hit the field
>> in minor releases of stable branches.
> I read that as we want it out in RC1 and make sure that works before we
> backpatch it to earlier branches.
I think we might as well back-patch now so we don't forget to do so.
rc1 will give us a chance to discover any problems, but if there are
any, we'd back-patch those fixes too.OK, fair enough if you think so. I'll go ahead and do that right away.
Done. I skipped 9.1 given it's status and that the backpatch didn't apply cleanly there (we moved code around).
Magnus Hagander <magnus@hagander.net> writes:
> Done. I skipped 9.1 given it's status and that the backpatch didn't apply
> cleanly there (we moved code around).
I think the same code exists in a different file in 9.1, but I concur
that it's probably not worth a lot of effort.
regards, tom lane