views:

20

answers:

1

I use Python to track the version between local SQLite and remote web page. It is useful to compare them by Last-modified and file size information from the HTTP response. I found something interesting during development.

def time_match(web,sql):
  print web,sql
  t1 = time.strptime(web,"%a, %d %b %Y %H:%M:%S %Z")
  t2 = time.strptime(sql,"%Y-%m-%d %H:%M:%S")
  print t1,t2
  if t1==t2:
    print "same time"
  else:
    print "different time"
  return t1==t2

In above code, I tried to decode the time from web and SQLite into internal time and compare them. Let us check out the print screen as following:

Wed, 13 Oct 2010 01:13:26 GMT 2010-10-13 01:13:26
(2010, 10, 13, 1, 13, 26, 2, 286, 0) (2010, 10, 13, 1, 13, 26, 2, 286, -1)
different time

The result shows me that the GMT is correctly decoded, while the default timezone datetime of Python seems as -1. My system timezone is actually +8, Where is the -1 comes from? SQLite?

+1  A: 

The -1 at the last position in the time.struct_time object does not mean you are in the 'UTC-01:00'. It represents the undefined attribute is_dst (since YYYY-MM-DD HH:MM:SS format does not contain any information on the current timezone or daylight saving time mode).

time.strptime('2010-10-15 11:01:02', '%Y-%m-%d %H:%M:%S')
# returns the following on a computer with Central European Sommer Time (CEST, +02:00):
time.struct_time(tm_year=2010, tm_mon=10, tm_mday=15, tm_hour=11, tm_min=1, tm_sec=2, tm_wday=4, tm_yday=288, tm_isdst=-1)
eumiro
Thanks! Since SQLite datetime doesn't support timezone, I have to remove TZ info before processing.
@user369257 - then be sure to store any datetime into your DB in UTC form and add utc tzinfo as soon as you read it from DB. This way you can work with it in DB without DST problems.
eumiro