How to manage atypical non-working days during a specific sprint

How do you handle the situation where you have gained new information during the Sprint that jeopardizes the Development Team's ability to meet the current Sprint Goal? Because in my opinion that is the exact situation you just described.  

Exactly what Daniel says.

Personally, looking at your options, there is one option which has effects on 1 sprint, and there is one option which effects 2 sprints. Going for consistency, I would go for the option with the least (side)effects. Next to that, changing sprint end date, and therefore changing the sprint length of the current sprint, is a big no no if you read the Scrum Guide. Even though the change might seem minimal, always stick to the SG. That said, you dont have to change the sprint end date, you can simply choose to have sprint ending events earlier.

In the end, the most important thing is: learn from it and move on ;)

Thank @Xander and @Daniel for your quick answers!!

I am at ease with 

How do you handle the situation where you have gained new information during the Sprint that jeopardizes the Development Team's ability to meet the current Sprint Goal?

Because the first thing that we have evaluated when we realized the new information, was thought about the Sprint Goal and made decisions to make it happen.

And I want to highlight this too

In the end, the most important thing is: learn from it and move on ;)

I really appreciate your opinion!

From the Scrum Guide in reference to the Sprint Planning event:

The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team. 

To me, there are two questions that jump out at me with this situation:

• if team capacity was considered, were the 2 holidays simply missed?
• if team capacity was not considered, why not?   It's right there in the Scrum Guide

In my opinion, this should not be treated like something that came out of nowhere mid-sprint.   Holidays are known well beforehand.

If there were truly an unanticipated impact to team capacity mid-sprint, that is a key benefit of the Daily Scrum.   The team should inspect and adapt based on their progress to date and their evaluation around meeting the Sprint Goal.

I generally agree with the advice you've received above, but to add some nuance about the Sprint Review, it is often worth considering the date and time that allows your key stakeholders to attend and participate.

Where I work, we run 2 week sprints from a Wednesday, with Sprint Reviews taking place on Tuesday afternoon. The time was chosen to allow our colleagues in New York  to participate (we're in Europe). We initially had them on Wednesday, but received feedback from our sales team that that particular day was their busiest time and they'd often struggle to attend.

In short, if it doesn't work for your stakeholders to attend a Sprint Review on Wednesday at particularly short notice, it might be more acceptable as an exception to have that event on a Monday.

Not that this is entirely down to the Development Team to have realized this, but perhaps it will help them anyway if they have a checklist of things to consider before forecasting what they can do. Known holidays would be an obvious thing to look at.

Thank you @Timothy and @Simon, I appreciate your opinion and highlights.