In 2016, Mark Ziemann, Yotam Eren, and Assam El-Osta published a short paper in Genome Biology that embarrassed an entire field. They checked 7,467 supplementary gene lists attached to 3,597 papers in 18 journals and found that 704 of those papers, roughly one in five, contained gene names that Microsoft Excel had silently converted into dates. SEPT2 became September 2. MARCH1 became March 1. The follow-up study by Abeysooriya, Ziemann and colleagues in PLOS Computational Biology (2021) scanned 11,117 articles and found the problem in 30.9% of them. The errors had not gone away; they had grown, partly because the scanning had improved.
Gene names are an unusual case, but the mechanism behind them is common: a field that looks simple, handled by software that makes assumptions nobody checks. Time is the most widespread example. Almost every dataset contains timestamps, and almost every research workflow involves a deadline. Both depend on time zones, daylight saving rules, and calendar conventions that most researchers never think about until something breaks. This article shows where those breakages happen and how to prevent them with a few simple habits.
A Timestamp Without an Offset Is Incomplete Data
The value “2026-10-25 02:30” looks complete, but it isn’t. Without knowing where it was recorded, it can refer to many different moments around the world, 24 hours apart at the extremes. Even with the location known, it can be ambiguous, as the next section shows.
The international standard ISO 8601 solves this by attaching the offset from Coordinated Universal Time (UTC) to every timestamp: 2026-10-25T02:30:00+02:00 refers to one moment and one moment only. The problem is that common research tools rarely store time this way by default. A spreadsheet date is a serial number counting days from a reference date, with no time zone attached. A survey platform may export responses in the server’s time zone, the respondent’s time zone, or UTC, and the column header does not always say which. Wearable devices, data loggers, and electronic lab notebooks each follow their own conventions.
Spreadsheets add another calendar quirk on top of this. Excel’s default date system treats 1900 as a leap year, a deliberate compatibility choice inherited from Lotus 1-2-3. Microsoft documents it, but few users know it exists. The nonexistent date February 29, 1900 has its own serial number, so any interval calculated across early March 1900 is off by one day. Few modern datasets reach back that far, but historical, demographic, and climate records do.
The Hour That Repeats and the Hour That Never Happens
Daylight saving time creates two predictable data problems every year in regions that use it.
In spring, one local hour disappears. On March 29, 2026, clocks in Central Europe jumped from 02:00 straight to 03:00. A device logging “02:30” local time on that date recorded a time that did not exist. In autumn, one local hour happens twice. On October 25, 2026, clocks across the European Union fall back at 01:00 UTC, so in Berlin, Paris and Madrid the hour from 02:00 to 02:59 occurs twice. In the UK it is 01:00 to 01:59. On November 1, 2026, the same thing happens across most of the United States and Canada between 1:00 and 1:59 a.m. local time.
Consider what this does to a dataset recorded in local time:
- Durations become wrong. A night-shift study that subtracts “22:00” from “06:00” on October 25 gets eight hours, but in Central Europe the participant actually worked nine. In March, the same calculation gives eight hours for a seven-hour shift.
- Records collide. Two sensor readings taken an hour apart can carry the same local timestamp in the repeated hour. Sorting by timestamp places them next to each other, and deduplication scripts may delete one as a duplicate.
- Daily aggregates change size. A “day” of data has 23 hours in spring and 25 hours in autumn. Daily totals of energy use, step counts, emergency visits or website traffic shift by about 4% on those dates for purely mechanical reasons.
That last point matters for research on daylight saving time itself. A study that finds more of some event on the Sunday the clocks fall back has to rule out the fact that the day had 25 hours.
Multi-site studies drift out of alignment
International collaborations face an additional problem: different regions change their clocks on different dates. In 2026, the United States moved its clocks forward on March 8 and Europe on March 29, three weeks later. In autumn, Europe falls back on October 25 and the US on November 1. During those gaps, the time difference between, for example, New York and London is one hour shorter than usual. A protocol that collects saliva samples “at 09:00 local time” at both sites, or schedules a joint online session “at 15:00 London time,” quietly changes its timing relative to the other site for those weeks.
The autumn gap between Europe and North America is always exactly one week, because the last Sunday of October and the first Sunday of November are always seven days apart. The spring gap is either two or three weeks, depending on how the Sundays fall in March. Both can be calculated years in advance, which means protocol designers can plan around them rather than discover them in the data.
An Offset Is Not a Time Zone
Many researchers who do record time carefully store the UTC offset, such as −05:00. That is better than nothing, but it is still not enough for data that will be reused for years. An offset describes one moment; a time zone is a set of rules that can change.
Governments change those rules regularly. Mexico abolished daylight saving time for most of the country in 2022. Egypt brought it back in 2023 after several years without it. Yukon moved to permanent year-round time in 2020. Each change means that the offset for a given city on a given date can no longer be calculated from old assumptions. Software handles this through the IANA time zone database, a public reference of the world’s time rules, updated several times a year. It identifies zones by region and city, such as America/Mexico_City or Africa/Cairo, not by abbreviation.
Abbreviations cause their own problems. CST can mean Central Standard Time in North America or China Standard Time. IST can mean India, Ireland, or Israel Standard Time. A dataset that records “CST” as its time zone without other context is genuinely ambiguous. A clear introduction to how world time zones are organized, including the role of UTC and the reasons offsets differ between countries, is a useful reference when designing a data-collection protocol that spans several regions.
The robust practice is to store two things: the moment in UTC, and the IANA zone name of the place where it was recorded. Together they allow any later analyst to recover local time correctly, even after rules change.
Instruments That Keep Their Own Time
Not every clock in a laboratory or field station runs on UTC. GPS receivers use GPS time, which does not count the leap seconds added to UTC since 1980 and is currently 18 seconds ahead of it. Unix timestamps, used by most computers and many logging devices, count seconds since January 1, 1970 and ignore leap seconds entirely. Standalone data loggers drift unless they are synchronized regularly.
For most social-science and clinical datasets, a few seconds don’t matter. For seismology, neuroscience, high-frequency finance, network measurement, or any study that merges streams from several instruments, they do. The leap-second problem is also changing: in 2022, the General Conference on Weights and Measures decided to stop inserting leap seconds into UTC by 2035. Long-running datasets that span the transition should document how each instrument handled time before and after it.
Deadlines: What “Anywhere on Earth” Actually Means
Time zones affect researchers not only in their data but also in their careers, through submission deadlines. Many conferences, especially in computer science and engineering, set deadlines as “end of day, Anywhere on Earth” (AoE). The convention was introduced in the IEEE 802.16 working group in the early 2000s by its chair, Roger Marks, to keep ballot deadlines geographically neutral. A deadline AoE has not passed as long as the date has not ended somewhere on Earth. In practice, that means the date has not ended in the UTC−12 zone, which covers only uninhabited Baker and Howland Islands.
The IEEE documentation makes the key conversion explicit: the end of a day AoE falls at 12:00 UTC on the following day. For a hypothetical deadline of October 30, 2026 AoE, that gives:
| Location | Local time when the deadline passes |
|---|---|
| UTC reference | 12:00, October 31 |
| New York (EDT, UTC−4) | 8:00 a.m., October 31 |
| London (GMT, UTC+0) | 12:00 noon, October 31 |
| Berlin (CET, UTC+1) | 1:00 p.m., October 31 |
| New Delhi (IST, UTC+5:30) | 5:30 p.m., October 31 |
| Tokyo (JST, UTC+9) | 9:00 p.m., October 31 |
The table also shows why researchers misread AoE deadlines in both directions. A researcher in Tokyo who assumes the deadline is midnight local time on October 30 submits 21 hours earlier than necessary. A researcher who assumes AoE means “local midnight, plus some leeway” may miss it entirely. The Berlin row shows another trap: since Europe falls back on October 25, the conversion that held throughout September no longer applies in the last week of October.
Funding agencies use different conventions, and these deserve the same attention. The US National Institutes of Health sets application deadlines at 5:00 p.m. local time of the applicant organization. EU Funding and Tenders Portal calls close at 17:00 Brussels time, which means a researcher in Lisbon or Helsinki must convert, and the conversion changes with daylight saving dates. Before planning around any deadline, check the exact local equivalent on a reliable world clock such as worldtimedata.com, instead of relying on memory of the usual time difference.
A Practical Protocol for Research Teams
Most of the problems above can be prevented at the design stage at little cost. The table below lists common practices and the safer alternative for each.
| Situation | Common practice | Safer practice |
|---|---|---|
| Storing timestamps | Local time, no offset | UTC in ISO 8601 format, plus the IANA zone name of the recording site |
| Naming time zones | Abbreviations such as CST or IST | IANA identifiers such as America/Chicago or Asia/Kolkata |
| Calculating durations | Subtracting local clock times | Subtracting UTC moments, then converting the result |
| Daily aggregates | Summing by local calendar day | Flagging 23-hour and 25-hour days, or normalizing per hour |
| Multi-site schedules | “09:00 local” at every site | Checking daylight saving dates for every site before fieldwork begins |
| Instrument clocks | Trusting the device | Recording the clock source (UTC, GPS, Unix) and synchronization method in the metadata |
| Spreadsheets | Opening CSV files directly in Excel | Importing date and identifier columns as text, or using R or Python |
| Deadlines | Assuming the usual time difference | Converting each deadline to UTC and to local time on the actual date |
Two items on this list cost almost nothing and prevent the most damage. The first is a single line in the data management plan stating the time standard used for every timestamp column. The second is a calendar check before any data collection that runs through late March, late October, or early November, the months when clocks change in Europe and North America. Neither requires special software, and both are much easier than reconstructing what “02:30 on October 25” meant two years after the data was collected.
The gene-name studies showed that silent conversions survive peer review because nobody looks for them. Time fields need the same attention. A reviewer who asks “in which time standard are these timestamps recorded?” asks one of the cheapest and most revealing questions in data review, and still one of the least common.
What’s a moment in your life that made you feel truly alive?
View all responses
