Time representation in biological time series

Time units

As strange as it may be, time units is not indicated nor imposed in ts objects. You are free to chose the one you like: second, minute, hour, day, week, month, year, century, etc. But as soon as you chose the unit, you must reexpress the time as a decimal value of this unit.

You are free to choose your time units, but that does not mean all time units are equals. There are better ones… and it depends on what you want to study in your time series. The best time unit is indeed the one that matches the main cycle you want to study. Hence, the two key time units are the day (for circadian cycles) and the year (for seasonal effects).

Days

If you are working with time series that focus on circadian effects, you should use the day as time unit. Then, time is reexpressed as a decimal fraction of a day. For instance, 0.5 is midday, 0.25 is 6 AM, etc. Since time is stored as numeric internally in R, it is already converted into decimal time. There is nothing to do, except to understand the concept of “a decimal fraction of a day”.

You don’t have to worry too much about leap seconds (although, it is useful to document you a little bit about it), but you should be very attentive to time zones, UTC time and all these concepts in order to properly convert you time into decimal fractions of a day. Otherwise, there is not much difficulties here.

Reasonable choices for the frequency of observations are 1 (every day), 2 (every twelve hours), 4 (every 6h), 12, 24, 48 (every 1/2h), 144 (every 10min), 288 (every 5min), or 1440 (every min). Of course, you can use any frequency you like.

Take care that the ts object with frequency = 12 or frequency = 4 will automatically assume that the time units is year and will print the data as months, or quarters respectively (see the nottem example). In the present case, it will be thus wrongly printed!

Years

The year unit is to be used when you work with seasonal effects, and interannual changes. This unit is much more problematic and in pastecs it is simplified into round sub-units, considering seasons (four subunits), or months (twelve subunits) also roughly equivalent to the other major cycle impacting biology: the moon cycle.

To avoid accumulated lags in long time series of tens of years, one year is considered to be 365.25 days. The function daystoyears() transforms your time, expressed in days into a year time unit that respects the convention of each year being exactly 365.25 days.

library(pastecs)
# A vector with a "days" time-scale (25 values every 30 days)
my_days <- (1:25) * 30
# Convert it to a "years" time-scale, using 23/05/2001 (d/m/Y) as first value
daystoyears(my_days, datemin = "23/05/2001", dateformat = "d/m/Y")
#>  [1] 2001.389 2001.472 2001.554 2001.636 2001.718 2001.800 2001.882 2001.964
#>  [9] 2002.047 2002.129 2002.211 2002.293 2002.375 2002.457 2002.539 2002.621
#> [17] 2002.704 2002.786 2002.868 2002.950 2003.032 2003.114 2003.196 2003.279
#> [25] 2003.361

As we can see here, time is now expressed as a decimal fraction of a year, or 365.25 days. The “natural” values you could choose for frequency are 4 (quarters or seasons), 12 (months), 24 (half-months), 48, 52 (“weeks”), 364 (“days”) or 384. But no mather what you choose, it won’t fit into actual calendar sub-units. For instance, for frequency = 12, you have something similar to months but perfectly equally spaced. No mather your month is 28, 29, 30 or 31 days long, in the decimal system used in tsobjects in pastecs, it will always be 1/12 of a “year” (as 365.25 days). It means one “month” is indeed:

365.25/12
#> [1] 30.4375

That is: 30 days, plus a fraction of a day that happens to be 0.4375! How can we manage that? Taken exactly as defined, it would make a problem because the hour of the day will shift from month to month, and year to year (each month does not start at the same hour).

To avoid the problem of the shift in hour, you must separate the circadian effect and the seasonal effect. In order to eliminate the circadian effect out of your data, you can consider measurements always taken at the same hour as a starting point. Another solution is to aggregate your measurements by day. Depending on your variable, the aggregation can be done as mean or median daily value, or min, max, or the sum for frequency of occurence of an event.

Hence, before using daystoyears() you must make sure you have no daily effect anymore in your data. Now, measurements are often planned on a weekly basis, and there are:

365.25/7
#> [1] 52.17857

… approximatey 52 weeks (plus 0.179) in a “year”. So you have to choose for frequency: either frequency = 48 as “four measurements per month”, but then, time interval is:

365.25/48
#> [1] 7.609375

seven days plus 14h and 24min, or frequency = 52, and you got much closer to your “real week”, with a difference of only roughly 35min. However, the choice of 52 is less optimal in term of months, because 52 does not divides exactly by twelve, while 48 does.

The same dilemna exists for “days”. Either you can choose frequency = 364, which matches the actual number of days (minus 1.25) and is a multiple of seven (exactly 52 “weeks” in 364 “days”), or you must consider frequency = 360 to get something as closer as possible to a “day”, while remaining a multiple of twelve. And if you want a multiple of 4, 12, 24, and 48 simultaneously, you must consider frequency = 384.

So, what?

• In pastecs, time is simplified to a decimal fraction of a time unit.

• Best time unit should match the main cycle you are interested in your time series: days for circadian cycle, years for seasonal cycle.

• With the days, you must just understand the notion of “fraction of a day”, and take care of the time zone in your conversion.

• With the years unit, you must understand that everything is not only transformed into decimal fraction of a year, but also that all units and subunits are exact divisions, and thus, they are not perfect matches of real sub-units in the Gregorian calendar like months, weeks, or days. It makes sense in the context of methods and tools used on time series to have exact subunits, plus, usually the living organisms do not really care if we are sunday or monday!

• Conversion from time expressed in days must be done with daystoyears() to take this into account, but only after making sure that the daily effect is eliminated (only use measurments made at the same hour, or aggregate data by days before transformation), because there will be a shift in the hours during the calculation. You can regularize you time series using regul(units = "daystoyears") to let pastecs manage all the gory details.

• It is convenient to adjust the frequency of observations into a round fraction of the year, with most useful values being 4 (quarters or seasons), 12 (months), 24, 48,… down to 384, which is the closest match to a “day”, while remaining divisible by 4, 12, 24 and 48.

• Another division of the year is based on the week (sampling campaigns are often week-based). The closest integer division of the year is then frequency = 52 for “weeks”, or frequency = 364 for “days”. But then, it is not perfectly divisible by the major year subunits like “months”. The closest match for the “days” to be divisible by twelve is frequency = 360.

• You should consider if you really need a frequency larger that 48 (or 52) to study interannual variations and seasonal cycles. It is often much better to aggregate data to frequency = 48, or frequency = 52 for “weeks”, instead of using one day or less as time interval because the extra data you got that way do not provide useful information at the year-unit level for, say, multi-decanal time series.

Flattened time in pastecs slightly distords the complex reality, but it has no noticeable impact on subsequent analyses of most biological/ecological time series. On the other hand, it greatly simplifies and speeds up calculations in a context where the lag of a time series (a shift in time by a constant value) is very often used in the computations.