R timeDate package - inconsistent time zones

Question

timeDate stores some US holidays in GMT time zone. Given that the difference between GMT and US time zones differs throughout the year due to daylight savings, US holidays should not be stored in GMT time zone.

• EST = GMT - 5 while not in daylight savings
• EST = GMT - 4 from 2nd Sunday of March to 1st Sunday of November. (aka EDT)

This could bring some issues. For example:

library(timeDate)
holidayEIA <- function(x){ c(holidayNYSE(x), 
                             USColumbusDay(x)@Data, 
                             USVeteransDay(x)@Data)}
HolidaysEIA <- holidayEIA (2015)

#Output:
NewYork
[1] [2015-01-01 00:00:00] [2015-01-19 00:00:00] [2015-02-16 00:00:00]
[4] [2015-04-03 00:00:00] [2015-05-25 00:00:00] [2015-07-03 00:00:00]
[7] [2015-09-07 00:00:00] [2015-11-26 00:00:00] [2015-12-25 00:00:00]
[10] [2015-10-11 20:00:00] [2015-11-10 19:00:00]

Here holidayNYSE is in EST/EDT time zone, while USColumbusDay and USVeteransDay are in GMT time zone. Have to do the following to equalize:

library(timeDate)
holidayEIA <- function(x){ c(holidayNYSE(x), 
                             USColumbusDay(x)@Data+ 14400, 
                             USVeteransDay(x)@Data+ 18000)}
HolidaysEIA <- holidayEIA (2015)

#Output
NewYork
[1] [2015-01-01] [2015-01-19] [2015-02-16] [2015-04-03] [2015-05-25]
[6] [2015-07-03] [2015-09-07] [2015-11-26] [2015-12-25] [2015-10-12]
[11] [2015-11-11]

This is not really a question, yet given SO is a Q&A site, allow me phrase it as one. Wouldn't you agree that timeDate should store holidays in local time zones, as well as store all holidays for each country under the same time zone?

Answer 1

I don't work a whole lot with R, but I'll address this part of your question:

Wouldn't you agree that timeDate should store holidays in local time zones, as well as store all holidays for each country under the same time zone?

No. Fundamentally, holidays should not belong to a local time zone, nor to GMT, nor to any other time zone. In the vast majority of cases, an occurrence of a holiday is simply a calendar date, consisting of year, month, and date.

Storing it with times in a local time zone wouldn't make sense when a holiday is observed in a country with multiple time zones (like the US). Likewise, it wouldn't make sense for a holiday like Christmas Day or New Year's Day that is observed by many different people around the world.

However, when a particular individual observes a holiday, then you can take the current time zone of that individual, apply it to the calendar date, and compute the time for the start of the day, and the start of the next day. Together, those values form a half-open interval [start, end) describing how the local "day" maps to universal time.

Keep in mind that not all local days start at midnight. Some time zones have DST transitions that exclude the midnight hour, having a spring-forward from 23:59:59 to 01:00:00.

Consider the following example:

• October 15th, 2017 in Brazil is the "Teacher's Day" holiday (per this list).
• It also happens to be the scheduled date of the spring-forward transition (as shown here).
• Stored in data, it should simply be a date: 2017-10-15.
• When observed by a particular person, you take into account their time zone.
• Brazil has multiple time zones, with standard time offsets ranging from UTC-2 to UTC-5 (see Wikipedia for details). Additionally, some of them observe DST and some do not.
• So Teacher's day in 2017 in São Paulo is [2017-10-15T01:00-02:00, 2017-10-16T00:00-02:00), while the same holiday in Manaus is [2017-10-15T00:00-04:00, 2017-10-16T00:00-04:00).
• Normalized to UTC, that's [2017-10-15T03:00Z, 2017-10-16T02:00Z) in São Paulo, but in Manaus it's [2017-10-15T04:00Z, 2017-10-16T04:00Z).

From this we can see that the concept of a "day" is not the same for everyone, neither in terms of absolute start and end, nor in terms of duration.