tl;dr
Definition of Daylight Saving Time (DST) changed between 1980 and 2016.
Previously DST ended on last Sunday of September, later changed to end on last Sunday of October.
Detailed Answer
The missing piece of the puzzle is knowing the specific time zone used in your calculations. Your Question and example code fails to tell us exactly what time zones were utilized. My discussion here assumes you used a time zone similar to that of Europe/Berlin (based on your use of text apparently localized in German language), in that its definition of DST changed.
CET and CEST are not actually time zones. Such abbreviations are not standardized, nor even unique. Avoid them.
Instead use proper time zone names as defined in the tz database. A true time zone is an offset-from-UTC plus a set of rules for handling anomalies past, present, and future, such as Daylight Saving Time (DST).
The time zone rules change, and change surprisingly often. Bored politicians, I suppose.
For example, Europe/Berlin changed in 1980 to end DST on last Sunday in September. So DST does not apply to your date of October 1980. Since 1996 EU rules apply, extending DST to last Sunday of October rather than September. Thus DST does apply to your October 10th date in 2016.
The code in the Question uses month “9” which actually means “10”, October. One of the many problems with the old java.util.Date class is that it counts months by zero-based counting, 0 = January. One of many many reasons to avoid the old date-time classes. In contrast, in java.time the month number for October is indeed 10 as you would expect, and you can use a constant from the Month enum to be even more clear.
By the way, another poor design choice in java.util.Date is that when constructing a Date object as you did in the Question, your JVM’s current default time zone was applied, and the result adjusted back to UTC. This further complicates your Question as you did not report the time zone in use at the time you ran your code.
By the way, JavaScript, like nearly every development platform, has poor support for date-time work. Try to use Java and its built-in java.time framework whenever possible. See Oracle Tutorial. You can witness java.time in action in the following example code. We get October 10th in 1980 and in 2016 for Europe/Berlin.
ZoneId zoneId = ZoneId.of ( "Europe/Berlin" );;
ZonedDateTime zdt_1980 = ZonedDateTime.of ( 1980 , Month.OCTOBER.getValue () , 10 , 0 , 0 , 0 , 0 , zoneId );
long seconds_1980 = zdt_1980.toEpochSecond ();
ZonedDateTime zdt_2016 = ZonedDateTime.of ( 2016 , Month.OCTOBER.getValue () , 10 , 0 , 0 , 0 , 0 , zoneId );
long seconds_2016 = zdt_2016.toEpochSecond ();
Dump to console.
System.out.println ( "zoneId: " + zoneId );
System.out.println ( "zdt_1980: " + zdt_1980 + " | seconds_1980: " + seconds_1980 );
System.out.println ( "zdt_2016: " + zdt_2016 + " | seconds_2016: " + seconds_2016 );
You can see in the results that the offset-from-UTC changed from one hour ahead of UTC (+01:00) in the old days to now two hours ahead of UTC (+02:00). The difference is because of the re-definition of DST.
So, this explains why you got "CET" in 1980 but "CEST" in 2016. The S in CEST that you got for 2016 means "Summer", and “Summer Time” means DST. In this year of 2016, most of October is in "Summer Time" (DST). In 1980, October was not in DST/"Summer Time"/"CEST".
zoneId: Europe/Berlin
zdt_1980: 1980-10-10T00:00+01:00[Europe/Berlin] | seconds_1980: 339980400
zdt_2016: 2016-10-10T00:00+02:00[Europe/Berlin] | seconds_2016: 1476050400
