0

I have a list of deadlines for various projects. Once every 3 months, I download the next 3 months' worth of deadlines as ICS files and add them to my calendar. Because I only download them once every 3 months, I am experiencing an issue with regards to daylight saving time (DST). Here is an example of the problem:

  • In January, I download the upcoming deadlines for February, March, and April, setting the time as 9:00 AM on their respective dates.
  • Come March 13th (the start of DST), the deadlines start to appear as 8:00 AM because when I downloaded them, it was not DST, so when we "sprung forward," what used to be 9:00 AM is now 8:00 AM, and the files are not compensating for that.

I have had trouble determining where the best way to solve this problem would be:

  • In the configuration of the ICS file itself. I imagine that if there was a place to do this, it would be here. I have scoured the documentation of ICS files and have yet to find something that would auto-compensate for DST in the future.
  • In JavaScript on the front-end. I know that JavaScript has the option of setting the timezone to a region ("America/New_York") instead of a time zone, which helps it auto-compensate for DST, but I have not been able to get that feature to work on a date in the future, as it only references the current time.
  • In PostgreSQL on the back-end. I have tried various versions of AT TIME ZONE to no avail. I encounter the same problem I did in JavaScript: It sets the time in the specified time zone without taking into account whether or not the date would be affected by DST in the future.

Update to Post to Include More Information

The deadline information (PROJECT_NAME and DUE_DATE) is extracted from a PostgreSQL database. The due date is stored as a DATE value like this: 05-MAR-22.

To add the time, I have taken two approaches:

  1. Adding the time in PostgreSQL like this:
select ('06-JUN-2022'::date + time '9:00') at time zone 'America/New_York'
  1. Adding the time in JavaScript like this:
deadline.DUE_DATE = deadline.DUE_DATE.split("T"[0] += " 09:00:00";

But neither method has helped me solve the timezone issue.

The JavaScript microservice sets the following fields:

BEGIN:VEVENT
UID:[ UID ]
SUMMARY:[ PROJECT_NAME ]
DTSTAMP:[ DTSTAMP ]
DTSTART:[ DTSTART ]
BEGIN:VALARM
ACTION:DISPLAY
TRIGGER:[ TRIGGER ]
END:VALARM
DURATION:PT
END:VEVENT

which seems to be missing a few important details for configuring the timezone.

squidslippers
  • 132
  • 1
  • 7
  • How are you generating the next 3 months' deadlines as ics files? Also, what calendar are you adding the ics file to? I ask because it is possible to configure the ICS file with a ["VTIMEZONE" component](https://icalendar.org/iCalendar-RFC-5545/3-6-5-time-zone-component.html), which requires adding a rule for the desired timezone, but in my opinion it is not the easiest method – gloo Jun 29 '22 at 19:36
  • I have a custom JavaScript microservice that creates the ICS files. I am downloading them to two calendars: The Apple calendar on iPhone and Microsoft Outlook. – squidslippers Jun 29 '22 at 19:39
  • You are going to need to provide example data and a flow chart of how that data moves through the system as it is not clear to me the distinction between the ICS data and the Postgres data? Also show what data type you are using to store the timestamps in Postgres. – Adrian Klaver Jun 29 '22 at 20:03
  • I'm beginning to think that the issue is actually with the JavaScript microservice that is generating the ICS files. Could you give an example or some insight into how it works? I suspect that when the files are generated, the timezones are being set as the pre-daylight-savings timezone, and this is causing the shift when viewing it after. – gloo Jun 29 '22 at 20:22
  • @AdrianKlaver, I updated the question with more information. Let me know what further questions you have. – squidslippers Jun 29 '22 at 20:29
  • @gloo, That makes an awful lot of sense. Thank you for your input and your answer. I will give it a shot. – squidslippers Jun 29 '22 at 20:29
  • So where is the time(9:00 AM) getting into this? A Postgres `date` if cast to a timestamp is going to become midnight: `select current_date::timestamp; 06/29/2022 00:00:00`. And it will need to be a `timestamp` if you want to apply time zone information. Before you get into making changes you need to create a diagram of how the timestamp is being created and how it is being moved through the stages. – Adrian Klaver Jun 29 '22 at 20:33
  • I just updated the post again to include that information. The tricky part is I have been messing with the ways in which the timestamp is being created/manipulated/passed in an attempt to solve the problem, so there is no standard way. I am thinking that if configuring it in the microservice that creates the ICS file is best, then I can work backwards from there and determine how to deal with the timestamp last. – squidslippers Jun 29 '22 at 20:41
  • Is the javascript microservice an external library or something you have more control over? – gloo Jun 29 '22 at 20:41
  • I have control over it. The package is pretty big, and I am unfamiliar with it—I have spent all my time looking in the wrong place and have not looked at that code—so I think I will look through that code to (1) see what changes I would need to make to get things working there and (2) figure out which pieces would be helpful to share to give you more context. – squidslippers Jun 29 '22 at 20:43
  • In `psql` what does `show timezone;` in the server? Or more to the point what does: `select ('06-JUN-2022'::date + time '9:00') at time zone 'America/New_York'` return in `psql`? – Adrian Klaver Jun 29 '22 at 20:47

1 Answers1

1

You have the option of embedding time zone information in the ICS file by utilizing the TZID parameter and VTIMEZONE component of ICS files. The VTIMEZONE component requires adding information about DST rules to the file, and each unique TZID must have a corresponding VTIMEZONE component. You can use tzurl.org which has generated VTIMEZONE definitions for every time zone. For more information about how to do this, you can refer to these related questions:

I am lacking some knowledge of the specific implementation details of Microsoft Outlook and Apple calendar, but I'm pretty sure that they would take such relevant information from the ICS file into account.

Look at how you are generating the ICS files with Javascript. It sounds like the timezone is being set to the pre-daylight-savings timezone, which will cause problems when viewing the event after the daylight savings shift. According to the ics specification:

The use of local time in a DATE-TIME or TIME value without the "TZID" property parameter is to be interpreted as floating time, regardless of the existence of "VTIMEZONE" calendar components in the iCalendar object.

This may also point to the possibility that the timezone is being set incorrectly, because if the "TZID"/"VTIMEZONE" components were not defined, the events should be regarded as "floating", or "the same hour, minute, and second value regardless of which time zone is currently being observed."

gloo
  • 681
  • 2
  • 12
  • Thank you! I was in the process of updating my question to include more details per Adrian's request, but I think you have given me the information that I needed. I will give this a shot. – squidslippers Jun 29 '22 at 20:26