Open ArnyminerZ opened 2 weeks ago
To reproduce:
@Test
fun testGuatemala() {
javaClass.classLoader!!.getResourceAsStream("events/guatemala.ics").use { stream ->
val events = Event.eventsFromReader(InputStreamReader(stream, Charsets.UTF_8))
assertEquals(1, events.size)
val event = events[0]
event.dtStart!!.let { start ->
val instant = Instant.ofEpochMilli(start.date.time)
val dateTime = instant.atZone(ZoneId.of("America/Guatemala"))
println(start.timeZone.id)
assertEquals(
ZonedDateTime.of(2024, 7, 3, 10, 0, 0, 0, ZoneId.of("America/Guatemala")),
dateTime
)
}
}
}
Fails with:
expected:<2024-07-03T10:00-06:00[America/Guatemala]>
but was: <2024-07-03T09:00-06:00[America/Guatemala]>
In any case, I think the timezone is directly not correctly defined in the ics. It doesn't specify any daylight saving, and "Central America Standard Time" is ambiguous I think, so that may be the issue here.
I agree:
Central America Standard Time
is mapped to US/Central
by the MS timezone transformation rules. The transformation happens before evaluating the actual MS timezone.US/Central
is an alias for America/Chicago
. So the DTSTART
is treated as if would have America/Chicago
timezone.America/Chicago
has DST, while Central America Standard Time
apparently doesn't (at least given the original VTIMEZONE
and some non 100% reliable information on the Web).I also found a table on unicode.org that suggests these mappings:
Central America Standard Time 001 America/Guatemala
Central America Standard Time BZ America/Belize
Central America Standard Time CR America/Costa_Rica
Central America Standard Time EC Pacific/Galapagos
Central America Standard Time GT America/Guatemala
Central America Standard Time HN America/Tegucigalpa
Central America Standard Time NI America/Managua
Central America Standard Time SV America/El_Salvador
Central America Standard Time ZZ Etc/GMT+6
I think Etc/GMT+6
would be the best choice because it's generic (although Etc/GMT+6
with plus actually means -06:00), or one of the cities/countries if it must be a city/country.
So as I understand it, this would have to be updated in ical4j in the MS outlook mapping file. @ArnyminerZ Can you please prepare an issue/PR for ical4j and link it as dependency?
Okay, I'll open a PR for that, however, I don't know if it will be released on 3. knowing that 4. is already stable...
This PR/issue depends on:
ICS files with the timezone "Central America Standard Time", which should be the one used in Guatemala. It looks like it gets converted to Chicago, which may break summer time I think.
The problem seems to come from files generated from Outlook.
Example ICS file: internal
Depends on https://github.com/ical4j/ical4j/issues/709