python - remote hosts timezone vs local

Question

I'm building a web frontend for remote logs monitoring,
having to manage about 10 different geographic locations I've bumped into the 3 headed hellhound some of you already have.

Is there any way to get from a remote HPUX shell variable the following remote info:

• zoneinfo (Country/City)
• UTC + offset (I can easily get this from the zoneinfo)

So far the best I could get is the OS abbreviated timezone (is this enough to iteratively cross the remote time with a statically built pytz.common_timezones collection and reverse convert the abbreviated zones into Country/City or I'm completely going the wrong way?)

I can easily get the offset after getting the Country/City (which I haven't)

datetime.now(pytz.timezone('Asia/Dili')).strftime('%Z %z')

'TLT +0900'

• get remote abbreviated timezone,

(Linux has the far more sane

grep "ZONE=" /etc/sysconfig/clock  

output like,
ZONE="Europe/London"
while HP-UX /etc/TIMEZONE uses abbreviated timezones like
TZ=CAT-2

I'd use echo $TZ which would output a little more useful data like CAT-2 but some remote HP-UXes don't even have this configured thus forcing me to rely on the ambiguous RFC822 date,

date +%z  

CAT

I've looked both into pytz, datetime.datetime, email.Utils but considering it's a no can do directly converting from abbreviated time into the zoneinfo Country/City (pytz allows the opposite)
should I just scratch this Don Quixote quest of autodiscovering the remote timezone and just add a Country/City dropdown list when accepting the user input registering the remote host?

EDIT (Partial solution)

building on @Mike Pennington answer

from datetime import datetime as dt
from datetime import timedelta as td
from dateutil.relativedelta import *
from email.Utils import mktime_tz, parsedate_tz

hpux_remote_date = 'Thu Apr 28 18:09:20 TLT 2011'
utctimestamp = mktime_tz(parsedate_tz( hpux_remote_date ))  

hpux_dt = dt.fromtimestamp( utctimestamp )
delta_offset = relativedelta(dt.utcnow(), hpux_dt)

hpux_utc = hpux_dt + delta_offset

# Sanity checking to ensure we are correct...
hpux_dt
datetime.datetime(2011, 4, 28, 18, 9, 20)
hpux_utc
datetime.datetime(2011, 4, 28, 9, 9, 22, 229148)

Answer 1

You should be able to find your GMT offset like this...

As a GMT offset, disregarding DST

(time.localtime()[3] - time.localtime()[8]) - time.gmtime()[3]

I am in Central time (GMT - 6) so, this yields -6 on my system.

As a GMT offset, including DST compensation

(time.localtime()[3]) - time.gmtime()[3]

This yields -5 on my system.

It's probably easiest to go with the second option and use it to convert those local HPUX times into GMT; then mangle with pytz as-required.

EDIT

If you are working with a text representation of remote (non-GMT) timestamps, it is probably easier to work directly with datetime objects... I don't have HPUX handy, but I'll assume the date string is similar to my debian squeeze system.

>>> from datetime import datetime as dt
>>> from datetime import timedelta as td
>>> # using os.popen() to simulate the results of a HPUX shell 'date'...
>>> # substitute the real HPUX shell date string in hpux_date
>>> hpux_date = os.popen('date').read().strip()
>>> hpux_dt = dt.strptime(hpux_date, '%a %b %d %H:%M:%S %Z %Y')
>>> # Rounding to the nearest hour because there *will* be slight delay
>>> # between shell string capture and python processing
>>> offset_seconds = ((dt.utcnow() - hpux_dt).seconds//3600)*3600
>>> hpux_gmt = hpux_dt + td(0,offset_seconds)
>>> # Sanity checking to ensure we are correct...
>>> hpux_gmt
datetime.datetime(2011, 4, 27, 17, 21, 58)
>>> hpux_dt
datetime.datetime(2011, 4, 27, 12, 21, 58)
>>> hpux_date
'Wed Apr 27 12:21:58 CDT 2011'
>>>