It is quite easy to get your system's timezone, as set in the OS, through JavaScript on the browser. Type these in the location/url:
javascript:alert(new Date())
javascript:alert(new Date().getTimezoneOffset())
The first shows the current time in your timezone, usually with a timezone offset and name, like "GMT-400 (EDT)". If that's too much parsing and math, the second shows minutes behind UTC. So if JavaScript is enabled, the site can get this value and stuff it in a field that gets submitted in a form, or simply send this info back to the server at any time.
So in addition to using a proxy to foil IP geolocation, you also need to disable JavaScript, which might break the site to some degree.
(And there are currently 40 timezones in use, not 24 -- some start at 30 and 45 minutes past the hour from UTC, and a few in the Pacific overlap by a day.)
EDIT: in addition to the timezone, you can also get your locale through the Date and Number objects: the order and separator for year, month, and day; and the thousands and decimal separators. Some combinations of these might, in a few cases, provide country-accurate location (or even slightly better -- it would be interesting to see a matrix of all the combinations).
Even if you could simply stub out Date and Number, that would probably break some useful functionality. So the best approach would be to modify the object prototypes so that they lie and use an arbitrarily chosen timezone and locale. That would require a fair amount of work on Date though; there are several related methods. For example, to force GMT:
Date.prototype.toString = Date.prototype.toGMTString;
Date.prototype.getTimezoneOffset = function() {return 0;};
// and about 10 more
As @barlop suggests, it looks like you can use Privoxy filters to modify the pages before they get to your browser. Due to (1) the way search and replace works with Privoxy, (2) the requirements of the patch, and (3) the flexible nature of HTML: you would have to apply the patch at the beginning of both the <head> and <body> (and even that is not 100% coverage).
The peers don't need to know your real IP, you are giving them a way to contact you by simply contacting them yourself.
Even if the tracker shares an unreachable IP (your VPN) and other peers fail to connect, directly at least, you make yourself reachable by contacting those peers yourself.
You may be blocking inbound requests from unknown hosts, but by contacting a peer and requesting data from it yourself you are initiating a two way data connection that they can use to not only send data, but to request it as well.
The VPN is probably doing exactly what you expect, blocking unknown host connections, but once you contact someone through it you have effectively established a two way pipe between you and a peer. Whenever your software gets an updated list of peers and contacts new peers then you will get new data flowing outwards as well as inwards.
Most home router firewalls (with UPNP disabled) will automatically block incoming connections as well which creates this same problem of peers not being able to connect to you. Once you start connecting to them (per the list supplied by your tracker) then you are effectively poking very specific holes in your firewall for communication to happen to (and from) very specific places. The VPN is essentially a remote firewall from this perspective.
Best Answer
It gets the information from your browser which gets it from your operating system.
If you change the information on your PC and you restart your browser, you'll get a different result.
I've done it myself in a web application where time is important. I check their browser's timezone with the timezone configured for their account (if any) and notify when there is a difference in the timezones.