We Keep Coding

How to compensate for daylight savings time in the future for ICS file calendar downloads

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:
Adding the time in PostgreSQL like this:
select ('06-JUN-2022'::date + time '9:00') at time zone 'America/New_York'
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.

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:
How to Specify Timezone in ics File which will work efficiently with google,outlook and apple?
What's VTIMEZONE used for in icalendar? Why not just UTC time?
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."

Getting different timezone IE11 and Chrome browser for jsTimezoneDetect js library

Getting different output for both browser if we select '(UTC +01:00) Brussels, Copenhagen, Madrid, Paris' in system.
var tz = jstz.determine();
var tzName = tz.name();
Output:
IE11: Europe/Berlin
Chrome: Europe/Paris

From the jsTimeZoneDetect docs:
Limitations
This script does not do geo-location, nor does it care very much about historical time zones. So if you are unhappy with the time zone "Europe/Berlin" when the user is in fact in "Europe/Stockholm" - this script is not for you. They are both identical in modern time.
Indeed, if we carefully examine and compare the history of time zone changes for Berlin and Paris, we find that they have been identical since 1980. Thus, unless your application is dealing with dates before 1980, it is inconsequential whether you detect Europe/Berlin or Europe/Paris.
As to which is more correct, the CLDR windowsZones.xml file (which is the canonical mapping between Windows and IANA time zones) contains the following:
<!-- (UTC+01:00) Brussels, Copenhagen, Madrid, Paris -->
<mapZone other="Romance Standard Time" territory="001" type="Europe/Paris"/>
Chrome uses the Intl API, which internally uses ICU, which contains the CLDR data. Thus, Chrome is providing the more correct answer. You should get the same answer in FireFox, Edge, and other modern web browsers.
Internet Explorer is older and doesn't contain the data needed to resolve this correctly. Thus, libraries like jsTimeZoneDetect (and also moment-timezone via moment.tz.guess()) first try to use the Intl approach, but when not available they make an educated guess by testing various known points in time for their UTC offset changes. Since it's just a guess, it's sometimes going to be imprecise.
If you are interested, there's a community-maintained compatibility chart that tracks which browsers support the "correct" time zone detection process. Expand the "DateTimeFormat" section and check the row labeled "resolvedOptions().timeZone defaults to the host environment"

toLocaleTimeString() behaviour without arguments in Chrome and Safari

I read in the MDN documentation that:
toLocaleTimeString() without arguments depends on the
implementation,the default locale, and the default time zone
What does this mean exactly?
And I tried the following code in both Chrome(Version 87.0.4280.88) and Safari browser(Version 14.0).
new Date().toLocaleTimeString()
in Chrome it gives output as
16:57:37
whereas in Safari it gives output as
4:57:37 PM
With regards to the above example can someone explain how the implementation is changing from one browser to another, and why is it so?
Edit:
All this was done using MAC, I tried changing preferred language under Setting -> "Language and Region" to English(US) it was English(India) before, as soon as I did that change and restarted chrome the result became.
4:57:37 PM
But for Safari without doing this change it was able to show in 12 hour format, what was the reason for that?

The specification for toLocaleTimeString states:
This function returns a String value. The contents of the String are implementation-defined, but are intended to represent the “time” portion of the Date in the current time zone in a convenient, human-readable form that corresponds to the conventions of the host environment's current locale.
with the definition of implementation-defined being:
An implementation-defined facility is one that defers its definition
to an external source without further qualification. This
specification does not make any recommendations for particular
behaviours, and conforming implementations are free to choose any
behaviour within the constraints put forth by this specification.
Therefore browsers are free to implement this feature as they see fit.

Node 8 vs 11 Timezone is different

Running a simple new Date().toString(). On Node 11, You get something like
'Fri May 10 2019 10:44:44 GMT-0700 (Pacific Daylight Time)'
While on Node 8 you get
'Fri May 10 2019 10:44:44 GMT-0700 (PDT)'
Note the different in timezone abbreviation. Why is that? And how can you force toString() to always return the zone in the abbreviation?

Stolen answer from #ssube who was too lazy to log in and post.
the whole Intl object and default formats were introduced between those two versions, which may have become the new default for Date as well.
After some digging on my own, and reading some of the Intl spec:
The ECMAScript 2015 Internationalization API Specification identifies time zones using the Zone and Link names of the IANA Time Zone Database. Their canonical form is the corresponding Zone name in the casing used in the IANA Time Zone Database.
As to how to revert back to an abbreviated timezone, I am seeing that there are several github repos that suggest using regex, others using an abbreviation Map, or even Ben Nadel who uses some regex to process the short timezone or long timezone, as seen in his blog here

Looks like JavaScript leaves this up to the implementer. Based on the below GitHub Issue for ECMA262, there are known differences between the ways UNIX & Windows handle the timezone value.
Across multiple JS implementations, it seems that Date.prototype.toString writes the timezone (in parens) in a long, locale-dependent form on Windows, but in a short form (2-4 letters) from the tz database on Unix-based OSes. More details in the V8 bug tracker.
The spec is really light on details for Date.prototype.toString:
Return an implementation-dependent String value that represents tv as a date and time in the current time zone using a convenient, human-readable form.
Does anyone have a good memory of why this is the definition? Looks like it goes all the way back to ES1.
Fortunately, it seems that, at this point, implementations have converged on something that's almost always the same, with the exception of the timezone string.
For the timezone string, would it be a good idea to pick one of the two alternatives and standardize it across all platforms? Does anyone have evidence one way or the other whether either of the two is likely to be more web-compatible, or whether we need to preserve the variation?
Additionally, it looks like there is still active discussion in the V8 Issues for Date.prototype.toString() normalization.
Going through the NodeJS there doesn't seem to be an explicit mention of this in their change logs for v10+.
Update
After digging through V8 commits, it looks like there is a new Timezone Names Cache implemented for performance in V8 when using Date.prototype.toString(). Based on the below excerpt from the message for this commit, it seems like this change is why there is a difference between Node v8 & Node v11
To speed up Date.prototype.toString(), this patch adds a cache in the
DateCache for the string short name representing the time zone.
Because time zones in a particular location just have two short names
(for DST and standard time), and the DateCache already understands
whether a time is in DST or not, it is possible to keep the result of
OS::LocalTimezone around and select between the two based on whether
the time is DST or not.
In local microbenchmarks (calling Date.prototype.toString() in a
loop), I observed a 6-10% speedup with this patch. In the browser, the
speedup may be even greater as the system call needs to do some extra
work to break out of the sandbox. I don't think the microbenchmark is
extremely unrealistic; in any real program which calls
Date.prototype.toString() multiple times, the cache should hit almost
all of the time, as time zone changes are rare.
The proximate motivation for this patch was to enable ICU as a backend
for timezone information, which is drafted at
https://codereview.chromium.org/2724373002/ The ICU implementation of
OS::LocalTimezone is even slower than the system call one, but this
patch makes their performance indistinguishable on the microbenchmark.
In the tz database, many timezones actually do have a number of
different historical names. For example, America/Anchorage went
through a number of changes, from AST to AHST to YST to AKST. However,
both ICU and the Linux OS interfaces just report the modern timezone
name in tests for the appropriate timezone name, even for historical
times. I can see why this would be:
- For ICU, CLDR only has two short names in the data file: the one for dst and non-dst
- For Linux, the timezone names do seem to make it into the /etc/localtime file. However, glibc assumes there are only two
relevant names and selects between them, as you can see in its
implementation of localtime_r:
http://bazaar.launchpad.net/~vcs-imports/glibc/master/view/head:/time/tzset.c#L573
So, this cache should be valid until we switch to a more accurate
source of short timezone names.

Rails Time Zone Mapping for browser detected Timezones

I am working on a application, which detects the browser's time zone and asks the user's to set the time zone to the browser detected values.
So, I have populated, a select drop down which list all the All the keys present in ActiveSupport::TimeZone::MAPPING.
Now, I have a user whose timezone is (GMT-08:00) Pacific/Pitcairn.
There are many such values which are not present in ActiveSupport::TimeZone.
How should I handle such values. I've checked many js files which claim to send in Rails Supported Values, but none of them seem to work.
If I set my timezone to UTC-08:00 in Windows machine then my javascript plugin detects a time zone and sends in a value of America/Los Angeles.
We have a check box to not allow DST Timings on Windows machine.
So in this case with UTC-08:00 as time zone and DST box unchecked we're getting a value Pacific/Pitcairn.
So to go with matching before / for two different values of America/Los Angeles and Pacific/Pitcairn it's not possible.
Set the value by UTC offset, by ignoring name also wouldn't help. We have two seperate value with (UTC-08:00) Pacific Time (US & Canada) and (UTC-08:00) for Tijuana. So how do I decide which value to set.
showTimeZoneInfo: function(member_time_zone, timeZoneInfo, invertTZHash){
var tzValue = jQuery().get_timezone({'defaultvalue' : 'Etc/UTC'});
var railsOffset = TimeZoneFlash.extractOffset(timeZoneInfo[member_time_zone]);
var browserOffset = TimeZoneUtils.zoneWithoutDST();
if ( railsOffset != browserOffset) {
jQuery(".time_zone_text").text(browserOffset + " " + invertTZHash[tzValue]);
jQuery('.cjs_display_time_zone').removeClass('hide');
}
}
Now we have a case where invertTZHash doesn't contain Pacific/Pitcairn. And It returns a undefined value.
I am working on building a alert box for users who are in a different time zone compared to their browser's timezone. Even Intl.DateTimeFormat().resolved.timeZone wouldn't help because most of my traffic is from IE and FF browsers

Time Zone != Offset. See the timezone tag wiki. So just swapping it for another time zone that happens to be on UTC-8 is not a good idea. You will pick up all the DST rules for that zone, which don't necessarily apply.
Even Pacific/Pitcairn isn't purely UTC-8 if you deal with past dates. It moved from UTC-08:30 to UTC-08:00 in 1998 - you can see that here.
This is one of the reasons I'm not happy with ActiveSupport::TimeZone. They make it quite clear in their docs that it is limited:
Limit the set of zones provided by TZInfo to a meaningful subset of 146 zones.
This seems rather arbitrary. Who is it that determines what is "meaningful" and what isn't? If it wasn't meaningful, it wouldn't have been in the database to begin with!
You should look at using the tzinfo gem, which is what ActiveSupport based theirs on anyway. It has the full TZDB with all of its time zone data instead of a limited subset.
Regarding time zone detection, I'm not sure what JavaScript you are using to "detect" the time zone. You show calling some functions get_timezone and TimeZoneFlash.extractOffset that must be custom to your app or provided by external libraries. Please elaborate on exactly what you're using.
The only timezone detection library for JavaScript that I am aware of is jsTimeZoneDetect - which makes it quite clear that it just takes an educated guess. Unless you are depending on the new internationalization APIs in the very newest Chrome an Opera (which I don't think you are), then there's no guaranteed way to detect a time zone without user involvement. See also this answer.
We have a check box to not allow DST Timings on Windows machine. So in this case with UTC-08:00 as time zone and DST box unchecked we're getting a value Pacific/Pitcairn.
Yes, that is an awful reality. IMHO - that should never be unchecked. It would be better if the checkbox wasn't there. Whether DST applies or not is handled by the time zone, so there's no good reason to disable it. I'm sure that they left it there specifically for cases like Pitcairn, because there isn't a Windows time zone entry for them specifically.
Update
From your comments:
I already have a drop-down for this. I am working on building a alert box for users who are in a different time zone compared to their browser's timezone.
Take the current offset from JavaScript using new Date().getTimezoneOffset(). (It's in minutes, and the sign is reversed, so you may need some simple math.) Compare it to the current offset for the selected time zone in your drop down. (You should be able to get that from your server-side code.)
If they don't match, then alert your user. No need for jsTimeZoneDetect at all for this.

First Option: Set by UTC Offset
Get the UTC Offset
Search for UTC offset in your ruby array.
Set value by UTC offset, ignore name. Choose the first timezone which has the correct UTC offset.
Some code for this:
timezone = ActiveSupport::TimeZone.all.select { |tz| tz.utc_offset == my_offset }.first
Second Option: Add a new Timezone to the list
If you know the UTC offset, add a new TimeZone to the list. See Docs.
Hope that helps!