python - remote hosts timezone vs local
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 remot开发者_StackOverflow中文版e 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-2I'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)
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'
>>>
精彩评论