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).
© Daniel FR @ Wikimedia Commons
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.2
- 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 8601
with 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) is performed on the last Sunday in March, whereas the second one (CEST ⇒ CET = UTC +02:00 ⇒ +01:00) is performed on the last Sunday in October. Different rules apply throughout the globe.1Once 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 -packages
zoo
and timeDate
might be of interest.The latter is quite useful, containing rule sets for more than 400 locations worldwide.
Vienna()
lists all switches between 1893 and 2099, e.g.:library(timeDate)
print(Vienna()[82:87, 1:4], row.names = FALSE)
Vienna offSet isdst TimeZone
2009-03-29 01:00:00 7200 1 CEST
2009-10-25 01:00:00 3600 0 CET
2010-03-28 01:00:00 7200 1 CEST
2010-10-31 01:00:00 3600 0 CET
2011-03-27 01:00:00 7200 1 CEST
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 1941/1942:
print(Calcutta()[, 1:4], row.names = FALSE)
Kolkata offSet isdst TimeZone
1854-06-27 18:06:32 21200 0 HMT
1869-12-31 18:06:40 19270 0 MMT
1905-12-31 18:38:50 19800 0 IST
1941-09-30 18:30:00 23400 1 +0630
1942-05-14 17:30:00 19800 0 IST
1942-08-31 18:30:00 23400 1 +0630
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 my CRO we had a LIMS (running on a UNIX-workstation 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…
- In some regions at midnight and/or on Friday (details).
- 02:15B is half an hour after 02:45A. Confusing, isn’t it?
Dif-tor heh smusma 🖖🏼 Довге життя Україна!
Helmut Schütz
The quality of responses received is directly proportional to the quality of the question asked. 🚮
Science Quotes
Complete thread:
- Actual times (beware of summer time switch)Helmut 2010-01-17 18:41 [Tips / Tricks]