2

I'm creating an ics file with PHP like this:

<?php
header('Content-type: text/calendar; charset=utf-8');
header('Content-Disposition: inline; filename=event.ics');
?>

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//My company//My name//DE
METHOD:PUBLISH
BEGIN:VEVENT
UID:<?php echo base64_encode(random_bytes(64))."\n";?>
LOCATION:At my house
SUMMARY:Meeting
DESCRIPTION:Important meeting
CLASS:PUBLIC
DTSTART:20210201T100000Z
DTEND:20210201T150000Z
END:VEVENT
END:VCALENDAR

The event starts at 10 o'clock and ends at 15 o'clock German time, as specified in the ics file. I'm located in Germany and I want to use the German time zone.

After downloading, I imported this in the Calendar app on my Mac. Unfortunately, the event gets created with starting at 11 o'clock and ending at 16 o'clock, instead of 10 o'clock and 15 o'clock, as specified in the ics file.

I think there's something wrong with the time zone. How can I set the right zone? What's the proper way to so that?

David
  • 2,898
  • 3
  • 21
  • 57
  • time in the card is UTC. For display purposes, apply a timezone. check `date_default_timezone_get` and `date_default_timezone_set`. Or use DateTime and provide appropriate DateTimeZone as second parameter... – Honk der Hase Jan 24 '21 at 11:34
  • @LarsStegelitz This won't affect the ics file since the date is already hard coded as 20210201T100000Z. Or did I get you wrong? – David Jan 25 '21 at 08:25

3 Answers3

0

The best way to configure timezone on PHP is to set it in configuration file

   TZID:Europe/London

Just change it accordingly to match your timezone.

Luke Shields
  • 31
  • 8
0

Your times are entered as UTC time and are displayed as local time after the download. If local times are given, you must convert them to UTC time for the ICS entry.. You can use gmdate() for this, for example.

jspit
  • 7,276
  • 1
  • 9
  • 17
0

The RFC5545 specification will help. It is useful to get familiar with it. https://www.rfc-editor.org/rfc/rfc5545#section-3.3.5 you will see there are 3 ways to specify a date-time, each way will have a different effect on how the date time is dealt with by the receiving application. Choose the way that makes the most sense for the events you are generating.

There are also many posts here on stack that may make it clearer if you find the spec hard to understand:

and so on

When testing future dates, consider that daylight saving of both the event timezone and the receiving calendar may also affect the time displayed.

Community
  • 1
  • 1
anmari
  • 3,830
  • 1
  • 15
  • 15
  • If I remove the trailing `Z` (like this: `20210201T100000`), this will be 10 o'clock in every calendar regardless of the time zone the calendar is using. Am I right? Since this `.ics` file will only be used by Germans located in Germany, isn't this the easiest way in this case? Or, do I miss something? – David Jan 25 '21 at 11:58
  • Exactly right - it’s ‘local’ everywhere - like a morning alarm. Consider if your Germans ever travel to another timezone ? Could just as easily put the TZID for Germany to remove any risk. – anmari Jan 25 '21 at 23:29
  • Like that? `TZID=Europe/Berlin:20210201T100000` – David Jan 26 '21 at 06:48
  • Looks right, but check the spec - there are examples there. – anmari Jan 26 '21 at 06:51
  • Thanks, but I don't really understand: Why is it enough for me to simply use `DTSTART;TZID=Europe/Berlin:20210201T100000` while others have about 20 lines just for the time zone like that: https://codeshare.io/21R0x3 – David Jan 26 '21 at 07:01
  • VTIMEZONE is a timezone definition - saying when the daylight saving changes happen. Strictly speaking one should include those at the top of any ics file to be 'valid' if one is using them. Applications seem to cope fine without -they have their own copies of the olson TZdata base definitions. https://en.wikipedia.org/wiki/Tz_database the VEVENT TZID says: this event uses this timezone. One can have multiple events from multiple different timezones. – anmari Jan 26 '21 at 07:10
  • In my opinion there are two possibilities: – David Jan 26 '21 at 08:45
  • If I use `DTSTART:20210201T100000` this will be always get imported as 10 o'clock, no matter what time zone the calendar uses. But this will result to problems if the calendar time zone gets changed, since the event uses the time zone that was active while importing. For instance, when the user was in another time zone when he imported the ics file. – David Jan 26 '21 at 08:45
  • `DTSTART;TZID=Europe/Berlin:20210201T100000` is the better choice, but only for people who know how to properly use a calendar. But what if a user doesn’t care about time zones, maybe because he usually enters his events manually, and uses a wrong (default) time zone? The calendar will „transfer“ the 10 o'clock Europe/Berlin to its own time zone. The calendar will show the right time for its time zone but the user doesn’t know that his calendar uses the wrong time zone and will appear at to wrong time to the appointment. – David Jan 26 '21 at 08:46
  • What do you thing about that? – David Jan 26 '21 at 08:46
  • Additional information: This is not like an alarm, that would have the same time in every time zone, e.g. check e-mails ever day at 10 o'clock. This is an appointment event where to people meet at a specific location at a specific time. – David Jan 26 '21 at 08:50
  • What do you think about this? – David Jan 28 '21 at 14:22
  • Personally I'd code things so they were 100% as intended by the specs. If the user has the wrong timezone on their calendar app, they'll soon figure it as all their other timed events will be off. – anmari Jan 29 '21 at 04:29