python - host remoti fuso orario locale vs

Question

Sto costruendo un'interfaccia web per i registri di monitoraggio a distanza,
dover gestire circa 10 diverse località geografiche ho urtato il 3 hellhound intestata alcuni di voi hanno già.

C'è un modo per ottenere da una variabile di shell remota HPUX le seguenti informazioni a distanza:

• zoneinfo (Paese / Città)
• GMT + offset (posso facilmente ottenere questo dal zoneinfo)

Finora il meglio che ho potuto ottenere è il fuso orario del sistema operativo abbreviato (Basta questo a modo iterativo attraversare il tempo a distanza con una collezione pytz.common_timezones costruita staticamente e convertito inverso le zone abbreviati in Paese / Città o Sono completamente andando nella direzione sbagliata?)

I possono facilmente ottenere l'offset dopo avere ottenuto il Paese / Città (che non ho)

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

'TLT 0900'

• get a distanza abbreviato fuso orario,

(Linux ha di gran lunga più sano

grep "ZONE=" /etc/sysconfig/clock  

output come,
ZONE = "Europe / London"
mentre HP-UX / etc / TIMEZONE usi fusi orari come
abbreviati TZ = CAT-2

userei echo $ TZ, che sarebbe uscita un po 'di dati più utili come CAT-2, ma alcuni HP-ussi remoti non hanno nemmeno questo configurato in tal modo mi costringe a fare affidamento sulla data di RFC822 ambiguo,

date +%z  

CAT

Ho guardato sia in pytz, datetime.datetime, email.Utils ma considerando che è un non può fare direttamente la conversione da tempo abbreviato in zoneinfo Paese / Città (pytz permette il contrario)
devo solo grattare questa ricerca don Chisciotte della autodiscovering fuso orario remoto e basta aggiungere un elenco a discesa Paese / Città quando accetta l'input dell'utente registrazione all'host remoto?

Modifica (soluzione parziale)

sulla base @ Mike Pennington risposta

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

Si dovrebbe essere in grado di trovare il vostro compensare GMT come questo ...

Come un offset GMT, ignorando DST

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

Sono nel tempo centrale (GMT - 6). Quindi, questo rese -6 sul mio sistema

Come un offset GMT, compresa la compensazione DST

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

Questo produce -5 sul mio sistema.

E 'probabilmente più facile andare con la seconda opzione e usarlo per convertire quei tempi HPUX locali in GMT; poi mangano con pytz come-necessario.

Modifica

Se si sta lavorando con una rappresentazione testuale di distanza (non GMT) timestamp, è probabilmente più facile da lavorare direttamente con gli oggetti datetime ... non ho HPUX a portata di mano, ma darò per scontato la stringa data è simile al mio sistema Debian squeeze.

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