iCAL DTSTART and DTEND format confusion. Should be easy to answer

Question

I'm writing an iCAL file. I work on a cruise ship and the file will basically be my itinerary for the next 6 months, which I want to share with other crew members, to be displayed on our phones (a mixture of iPhones and Android phones). I want to included the name of the port we visit, and the arrival and departure times. So far, so easy.

BUT, on a cruise ship we pass through different time zones on an almost daily basis. Some people use local carrier info to set their phone timezones, others adjust the timezone manually, and some don't bother doing either. I tried this once before, but got very confused with TIMEZONE formats: whether to use UTC with a 'Z' prefix, whether to specify the country codes, etc.

HOWEVER, a recent bit of googling turned up the 'floating' DTSTART and DTEND format, aka 'Local Time', which seems to do away with all the region and timezone specifications. So, am I right in thinking the following will work?

(Source data: 23 Nov, Rio De Janeiro, 8:00am to 6:00pm,
and 25 Nov, A Different Port, 10:00am to 8:30pm)

    BEGIN:VCALENDAR
    VERSION:2.0
    PRODID: MyNameHere
    BEGIN:VEVENT
    UID:[email protected]
    DTSTAMP:20171123T080000Z
    DTSTART:20171123T080000
    DTEND:20171123T180000
    SUMMARY:Rio De Janiero
    END:VEVENT
    .
    BEGIN:VEVENT
    UID:[email protected]
    DTSTAMP:20171125T100000Z
    DTSTART:20171125T100000
    DTEND:20171125T203000
    SUMMARY:Another Port
    END:VEVENT
    .
    .
    BEGIN: VEVENT
    (next event here)
    END VEVENT
    END:VCALENDAR

And if that syntax IS correct, then do I still need to specify DTSTAMP:20171123T080000Z with the 'Z' suffix? (something I read on https://www.kanzaki.com/docs/ical/dtstamp.html said that the 'Z' suffix is mandatory, even though I don't WANT to use UTC - I just want floating start and end times.)

Also, should the DTSTAMP time be the same as the DTSTART time for each event, or do I use the same one for each event?

I hope you can help

Thanks

Miles,
Musician,
Celebrity Infinity

Answer 1

Using floating time means that the timezone that's actually used, is actually in the timezone of the viewer of the event.

So if you schedule something at 8PM floating time, and: "User A" has their timezone set to Eastern, and it's 7:55pm, the event will occur 5 minutes from now, then user "B" who has their phone set to Central time will see that the event starts one hour + 5 minutes from now.

In other words, using floating time means that the actual time as viewed by the user is going to depend on the viewer of the event.

This is not what you want. Because you are going to arriving and departing at fixed points in time. You really have two options:

1. Use UTC.
2. Use local time + a timezone of the port

UTC might be simpler in your case, but there's a caveat. You mention Rio De Janairo, and Brazil's treatment of DST (daylight savings time) has not been stellar.

So it's possible that you plan to arrive your ship at 2PM localtime somewhere, but a few weeks before you do, the Brazilian government decides to postpone or scrap daylight savings time that year. The question is then, does the boat depart an hour later (still 2PM local time) or does it depart at the exact same time from a UTC perspective?

You might consider this an edge case and make adjustments if needed, when they do but I thought it was worth talking about this scenario.

Anyway, ignoring that, both "local time + TZ" or "UTC" will probably be good enough for you. If you use "America/Sao_Paulo" for a departure time, and people:

• Automatically got a time and timezone from a carrier, it will "just work"
• Manually changed their timezone, it will "just work"

I think I would prefer the local time + TZ because it's the most 'accurate' representation of the event.