dateHelperVCalendar.js: make timezone independent

[BacLuc]

As you can see in https://github.com/BacLuc/ecamp3/actions/runs/7315399347, the pdf tests only work if the TZ is set to UTC.
This is because the .utc got forgotten here.

The further plan is to run the frontend and pdf tests in multiple timezones, that we detect this sooner.
But only after #4316 when i can use matrix jobs without breaking the required status checks.

[github-actions]

⛔ Feature branch deployment currently inactive.

If the PR is still open, you can add the deploy! label to this PR to trigger a feature branch deployment.

[usu]

This is not a bug, this is a feature 😄

The reason is that VCalendar always runs in local timezone (there's no functionality to set the timezone of VCalendar). Because our values in DB are always stored as UTC, we need to have this conversion from UTC -> local and back.

This means that testing the conversion functions is TZ-dependent (by design).

I thought we improved the test experience by overriding the TZ with a known value (#3837), but seems this is not working in that case.

[BacLuc]

We did do it for the frontend, but not for the pdf module.
Ok, so i have to think a little about it.
The name is a little irritating, because unix timestamps are in UTC per definition (https://en.wikipedia.org/wiki/Unix_time).
Thus there should be no timezone shift in this function converting timestamp to UTC string.
The jsdoc string says that the timestamp is in local timezone, but this makes no sense looking at the standard.

The scary part ist that ScheduleEntries are missing in the picasso of the pdf module depending on the time zone.
It seems i have to dig deeper.

[usu]

We did do it for the frontend, but not for the pdf module. Ok, so i have to think a little about it. The name is a little irritating, because unix timestamps are in UTC per definition (https://en.wikipedia.org/wiki/Unix_time). Thus there should be no timezone shift in this function converting timestamp to UTC string. The jsdoc string says that the timestamp is in local timezone, but this makes no sense looking at the standard.

The scary part ist that ScheduleEntries are missing in the picasso of the pdf module depending on the time zone. It seems i have to dig deeper.

Yeah, I see how the naming can be confusing.

If you for example take the 2nd function utcStringToTimestamp, this function is doing 2 things:

• Convert from string to timestamp format
• Time shift to the new timezone in order to retain date + time

So a better comment might be:
// converts ISO String format (interpreted in UTC timezone) into a UNIX ms timestamp (retaining date + time, when interpreted in local computer's timezone)

Regarding pdf+print: As they both don't use VCalendar anymore, I think we should refactor them to not use this hack. This should not be necessary anymore.

[BacLuc]

Superseeded by #4329