Misinterpreted timezone

[treiher]

The following event is supposed start at 15:00 CEST, but biweekly says it starts at 17:00 CEST:

BEGIN:VCALENDAR
PRODID:-//Prod//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
UID:12345
DTSTAMP:20250514T080000Z
SUMMARY:
DESCRIPTION:
DTSTART;TZID=Europe/Berlin:20250519T150000
DTEND;TZID=Europe/Berlin:20250519T160000
LOCATION:
STATUS:CONFIRMED
SEQUENCE:1
CLASS:PRIVATE
END:VEVENT
BEGIN:VTIMEZONE
TZID:Europe/Berlin
BEGIN:DAYLIGHT
DTSTART:20250519T150000
TZNAME:CEST
TZOFFSETTO:+0200
TZOFFSETFROM:+0200
END:DAYLIGHT
END:VTIMEZONE
END:VCALENDAR

  biweekly.property.DateStart [ parameters={} | value=Mon May 19 17:00:00 CEST 2025 ]
  biweekly.property.DateEnd [ parameters={} | value=Mon May 19 18:00:00 CEST 2025 ]

Is this a bug in biweekly or is this object somehow malformed? Other libraries (e.g., collective/icalendar and hoodie/icalendar) return the expected time.

[mangstadt]

Your local computer's timezone must be two hours ahead of "Europe/Berlin" time.

When you call toString() on the DateStart and DateEnd properties, it uses your local computer's default timezone to generate the date string.

When outputting date strings in Java, you must specify the timezone you want to format it in. Because the timezone in the iCal is different from your local computer's timezone, you must tell it to use the timezone in the iCal, like so:

VEvent event = ical.getEvents().get(0);
DateStart start = event.getDateStart();

TimeZone tz = ical.getTimezoneInfo().getTimezone(start).getTimeZone();
DateFormat df = DateFormat.getDateTimeInstance();
df.setTimeZone(tz);
System.out.println(df.format(start.getValue()));
//outputs "May 19, 2025 3:00:00 PM"

[treiher]

Thanks for your response! If my local timezone had been two hours ahead, the result would have made sense. However, my computer's timezone is set to "Europe/Berlin". So this cannot be the cause.

I just rerun the reproducer and now it shows the right time:

  biweekly.property.DateStart [ parameters={} | value=Mon May 19 15:00:00 CEST 2025 ]
  biweekly.property.DateEnd [ parameters={} | value=Mon May 19 16:00:00 CEST 2025 ]

However, as soon as I set an event date in the future, the problem occurs again:

diff --git a/example.ics b/example.ics
index 6c4bedd..737e287 100644
--- a/example.ics
+++ b/example.ics
@@ -5,11 +5,11 @@ CALSCALE:GREGORIAN
 METHOD:REQUEST
 BEGIN:VEVENT
 UID:12345
-DTSTAMP:20250514T080000Z
+DTSTAMP:20260514T080000Z
 SUMMARY:
 DESCRIPTION:
-DTSTART;TZID=Europe/Berlin:20250519T150000
-DTEND;TZID=Europe/Berlin:20250519T160000
+DTSTART;TZID=Europe/Berlin:20260519T150000
+DTEND;TZID=Europe/Berlin:20260519T160000
 LOCATION:
 STATUS:CONFIRMED
 SEQUENCE:1
@@ -18,7 +18,7 @@ END:VEVENT
 BEGIN:VTIMEZONE
 TZID:Europe/Berlin
 BEGIN:DAYLIGHT
-DTSTART:20250519T150000
+DTSTART:20260519T150000
 TZNAME:CEST
 TZOFFSETTO:+0200
 TZOFFSETFROM:+0200

  biweekly.property.DateStart [ parameters={} | value=Tue May 19 17:00:00 CEST 2026 ]
  biweekly.property.DateEnd [ parameters={} | value=Tue May 19 18:00:00 CEST 2026 ]

[mangstadt]

The updated iCal file in your response still outputs 15:00 and 16:00 for me when I use the code in my previous response. Could you post a complete code sample of how you are generating that output?

Calling DateStart.toString() formats the timestamp according to your JVM's default timezone. It does not format the timestamp according to the timezone definition in the iCal file.

Just because the timezone definition in the iCal file has a TZID of "Europe/Berlin" doesn't necessary mean it represents Europe/Berlin time. TZID is simply a unique identifier used for the purposes of assigning the timezone definition to a property.

[treiher]

Calling DateStart.toString() formats the timestamp according to your JVM's default timezone. It does not format the timestamp according to the timezone definition in the iCal file.

Just because the timezone definition in the iCal file has a TZID of "Europe/Berlin" doesn't necessary mean it represents Europe/Berlin time. TZID is simply a unique identifier used for the purposes of assigning the timezone definition to a property.

I understand that TZID can be any name. Am I right that the deciding factor is TZOFFSETTO/TZOFFSETFROM? If my computer's time zone has the same offset, shouldn't the output be the same whether or not the time zone is explicitly set?

Here is a code sample and the output for the two events shown above:

        File file = new File("example.ics");

        ICalendar ical = Biweekly.parse(file).first();

        VEvent event = ical.getEvents().get(0);
        DateStart start = event.getDateStart();

        TimeZone tz = ical.getTimezoneInfo().getTimezone(start).getTimeZone();
        DateFormat df = DateFormat.getDateTimeInstance();
        System.out.println("Without timezone: " + df.format(start.getValue()));
        df.setTimeZone(tz);
        System.out.println("With timezone:    " + df.format(start.getValue()));

For the event in the past:

Without timezone: 19.05.2025, 15:00:00
With timezone:    19.05.2025, 15:00:00

For the event in the future:

Without timezone: 19.05.2026, 17:00:00
With timezone:    19.05.2026, 15:00:00

Is there an explanation why I get different start times depending on whether the event is in the past or in the future if no timezone is set explicitly?

[mangstadt]

The timezone definition in the iCal file must not match the definition of the real Europe/Berlin timezone, as defined by your JVM's default timezone.

This is what I get on my machine:

For the event in the past:

Without timezone: May 19, 2025 9:00:00 AM (default JVM timezone is America/New_York)
With timezone:    May 19, 2025 3:00:00 PM

For the event in the future

Without timezone: May 19, 2026 11:00:00 AM (default JVM timezone is America/New_York)
With timezone:    May 19, 2026 3:00:00 PM

[treiher]

So why do you get different start times depending on whether the event is in the past or in the future when the default JVM timezone is used (9:00 AM vs. 11:00 AM in your case)?

[mangstadt]

I think I understand now. Not sure what's going on.

The table below shows how the event's start time is displayed under various conditions. I would think that, when formatted as UTC, it should always be displayed as 13:00 because the timezone definition in the iCal file is +2:00 UTC, and 15 minus 2 is 13.

When I change the values of the VTIMEZONE's DTSTART property and the VEVENT's DTSTART property, I get inconsistent results in many places. The date always displays correctly when formatted under the VTIMEZONE definition.

VTIMEZONE's DTSTART value	VEVENT's DTSTART value
	20250519T150000	20260519T150000
20250519T150000	JVM: 09:00, VTIMEZONE: 15:00, UTC: 13:00	JVM: 08:00, VTIMEZONE: 15:00, UTC: 12:00
20260519T150000	JVM: 11:00, VTIMEZONE: 15:00, UTC: 15:00	JVM: 11:00, VTIMEZONE: 15:00, UTC: 15:00