RE: cothread time stamp problem

[<michael.abbott@diamond.ac.uk>]

Hi Guobao,

 

I’ve looked into the code and I think I’ve made a horrible mistake.  Can you try the following patch and let me know if it fixes things for you:

 

diff --git a/cothread/dbr.py b/cothread/dbr.py
index 655bf49..d2acc36 100644
--- a/cothread/dbr.py
+++ b/cothread/dbr.py
@@ -150,8 +150,13 @@ class ca_float(float):
     __doc__ = ca_doc_string
 
 
-# The EPICS epoch begins 1st January 1990.
-EPICS_epoch = int(time.mktime((1990, 1, 1, 0, 0, 0, 0, 0, 0)))
+# The EPICS epoch begins midnight first thing on 1st January 1990 and is in UTC.
+# We convert all EPICS timestamps to the Python epoch.  This is not defined in
+# the language documentation but in practice is the ANSI epoch, midnight 1st
+# January 1970.  Strictly we should compute
+#   EPICS_epoch = calendar.timegm((1990, 1, 1, 0, 0, 0, 0, 0, 0))
+# but that pulls in an extra module dependency and the number is constant:
+EPICS_epoch = 631152000             # Seconds from 1970 to 1990
 
 
 class ca_timestamp(ctypes.Structure):
 

 

Of course, the problem is that:

 

1.       EPICS timestamps are in UTC, as they ought to be

2.       The mktime() function is localised, so I shouldn’t have used it

3.       The correct function, timegm(), is less widely known (a GNU extension to libc, for example)

4.       At Diamond our time zone is GMT which is at most one hour away from UTC

5.       I have a horrible feeling I’ve only looked closely at timestamps during the winter (when GMT=UTC)

6.       oops

 

Do you have any more bugs in the pipeline?  I’m looking hard now!

 

I’ve pushed this patch to git, but will hold off on a release for a few days yet.

 

 

From: Shen, Guobao [mailto:shengb@bnl.gov]
Sent: 11 February 2012 03:59
To: Abbott, Michael (DLSLtd,RAL,DIA)
Cc: tech-talk@aps.anl.gov
Subject: cothread time stamp problem

 

Hi Michael,

What is the time policy used in cothread to retrieve ioc time stamp?

I am using cothread 2.3, and found the time is shifted by a constant value relative to local timezone.

For example, in US EST time, to get time stamp in Python, I use val = caget(pv, format=FORMAT_TIME).

However, the time.localtime(val.timestamp)=real local time + 5 hours, and 

time.gmtime(val.timestamp) = real local time + 10 hours = real UTC time + 5 hours,

which looks shifting to wrong direction.

 

Here is my test case:

$ caget -d 20 test
test
    Native data type: DBF_DOUBLE
    Request type:     DBR_TIME_DOUBLE
    Element count:    1
    Value:            1.9
    Timestamp:        2012-02-10 15:27:21.645387
    Status:           NO_ALARM
    Severity:         NO_ALARM

$ python
...
>>> from cothread.catools import *
>>> import time
>>> v=caget('test', format=FORMAT_TIME)
>>> time.localtime(v.timestamp)
time.struct_time(tm_year=2012, tm_mon=2, tm_mday=10, tm_hour=20, tm_min=27, tm_sec=21, tm_wday=4, tm_yday=41, tm_isdst=0)
>>> time.gmtime(v.timestamp)
time.struct_time(tm_year=2012, tm_mon=2, tm_mday=11, tm_hour=1, tm_min=27, tm_sec=21, tm_wday=5, tm_yday=42, tm_isdst=0)

Any suggestion?

Guobao

 

-- 

This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom