How do guessed time zones really work?

This question pops up every now and then, especially when the timezone guessing goes wrong for someone. So, here are some dirty details, which I just posted on the APRSSIG mailing list.

The aprs.fi service tries to guess where each site visitor is located. It's based on the IP address of the visitor, nothing else. Yes, it could be based on your default map start location, thank you, that's a good idea. Then, it looks up the timezone for the guessed city, which is pretty straightforward and works just fine. The guessing results are stored in a cookie, and you can force a retry by deleting the cookies set by aprs.fi.

For some areas, the visitor location guessing code simply guesses wrong. It works just fine for most people, and for some, it always gets it wrong. For example, it thinks everyone working for Nokia (Corporation) are actually located in the city of Nokia, Finland.

Currently the only real option is to select UTC in the Options window of aprs.fi, which, of course, does not really fix the problem. I should do a proper "pick any timezone" selection, like openaprs has. It's actually been "half done" for about a year now - I have the timezones database loaded in already.

The complication here is that the some of the time formatting happens on the client computer's side (in the Javascript code which runs on your web browser). Over there I can practically only select between UTC and the local time as decided by your web browser / operating system. There are no javascript localtime conversion functions which would take an arbitrary timezone definition (at least I couldn't find them :), and it'd be a pain to reimplement them with the DST stuff and everything. The "guessed" local time will be whatever you have selected in your operating system.

So, to do arbitrary timezone selection properly, I'll have to move all of the localtime conversions from the client-side code to the server side, and that'll make things marginally slower for everyone. Now the server is just giving Unix-style timestamp integers (seconds since 1.1.1970 00:00:00 UTC) to everyone who is looking at the real-time map, and the web browser gets to do the localtime conversion when it's needed. If your operating system knows your proper timezone, you'll notice that the real-time map view (the target info balloons etc.) gets it just right.

Yes, I'm going to do this eventually. The performance hit is marginal, it'll just eat a bit more memory on the web browser's side (to store the text strings for the timestamps in addition to the small integers), and a bit more CPU on the server side (to do the conversions for everyone). I'm trying to keep track of all of these and gain a little bit of extra performance everywhere I can, to keep things running quickly.

PS. I've been in Kuopio this weekend, installing the OH7RDA digipeater together with the local guys from my old home town. Thanks OH7RJ, OH7TB, OH7VM, OH7FDN. It's at a pretty high location, on the roof of a big hospital building, which is on a top of a hill. 3*5/8λ vertical, 20W, TNC2 with JKISS, digi_ned on a Linux PC, with a CompactFlash card instead of a hard drive. I'll try to document the setup with some photos later. It's nice to do some hardware hacking for a change! It'll be interesting to see how the digipeater's heard stations map develops for this new digi. Tomorrow morning, on the way home, I'll offer it some traffic on the south side of the city.