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: 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'
    >>>
    

