Actual times (beware of summer time switch) [Tips / Tricks]
writing a protocol for a multi-center multiple dose PK study reminded me on the issue of summer time (en-UK) / daylight saving time (en-US).
Especially the autumn switch might be confusing, since there are two [sic] local time intervals from 02:00–03:00; in local time these hours are denoted by suffixes A and B.*
- In autumn your washout may be shorter (if e.g., one week is used: no big deal 167 h vs. 168 h).
- If your profiles extend over a “switch day”, you may measure different tz-time points in two periods.
- In multiple dose studies beware of dosing intervals: If 24 h are intended, you may end up with 23 h or 25 h…
The best way to handle the issue is to use the universal time (UTC). Actual sampling times should be coded according to
ISO 8601with offset to UTC (example for Central Europe: YYYY-MM-DD HH:MM:SS +01:00; alternative notation: YYYY-MM-DD HH:MM:SS CET). In the EU the first switch (CET⇒CEST = UTC +01:00⇒+02:00) takes place on the last Sunday in March, whereas the second one (CEST⇒CET = UTC +02:00⇒+01:00) takes place on the last Sunday in October. Different rules apply throughout the globe…
Once you have got sampling times in ISO 8601, you may set up your PK database taking the offset into account – I would suggest to set the base to your local time without DST (not to UTC).
Caution: You have to improvise, since I’m not aware of any PK software handling the ISO-format with offset. Pharsight’s Phoenix (like Excel) supports the ISO-format, but only without offset. The R packages
timeDatemight be of interest.
The latter is quite useful, containing rule sets for more than 400 locations worldwide.
Vienna()lists all switches between 1901 and 2037, e.g.:
The ISO-date/time gives the switch in UTC, the difference in seconds to UTC, a flag (DST on/off), and the ISO timezone code.
Vienna offSet isdst TimeZone
82 2009-03-29 01:00:00 7200 1 CEST
83 2009-10-25 01:00:00 3600 0 CET
84 2010-03-28 01:00:00 7200 1 CEST
85 2010-10-31 01:00:00 3600 0 CET
86 2011-03-27 01:00:00 7200 1 CEST
87 2011-10-30 01:00:00 3600 0 CET
Nice for our Indian friends because they would have faced the problem only once back in 1942;
Calcutta offSet isdst TimeZone
1 1901-12-14 20:45:52 21200 0 HMT
2 1941-09-30 18:06:40 23400 0 BURT
3 1942-05-14 17:30:00 19800 0 IST
4 1942-08-31 18:30:00 23400 1 IST
5 1945-10-14 17:30:00 19800 0 IST
Another option would be to set up a local timebase (essentially ignoring the switch). Some EDC systems might allow for that. Great, if you still use paper CRFs. But: It would need clear communication between staff and volunteers about the consequences. If in spring (before the switch) sampling starts at 08:00, in the second period the corresponding time point should be sampled at 09:00. Again no big deal in single dose studies, but may be tricky in a MD study, where subjects come to the clinical site for dosing in the saturation-/switch-over phase…
PS: A short personal story. In the CRO I was working for, we had a fancy LIMS (running on a UNIX-machine acting as a local timeserver for all connected equipment; so time-format was not an issue – as we believed). Administration, sampling, and centrifugation were registered by barcode readers. Of course we were hit during an MD study in spring. At the end of the study I clicked the button to get the list of deviations of actual from scheduled sampling times – expecting 10–20 lines fitting on a single sheet of paper as usual. But the printer wouldn’t stop…
- 02:15B is half an hour after 02:45A. Confusing, isn’t it?
The quality of responses received is directly proportional to the quality of the question asked. ☼
- Actual times (beware of summer time switch) Helmut 2010-01-17 18:41 [Tips / Tricks]