Closed jcaron23 closed 5 years ago
This appears to only be an issue when NOT running with --pure. I'll look into it.
@winterz Have you seen this problem? I can't find the root cause.
I always use --pure because it produces better output and I would hope/expect that Outlook can handle ALL legal VTIMEZONEs by now. If this is indeed the case, perhaps we could/should make --pure the default
Looks like the problem started here: https://github.com/libical/vzic/commit/c98e4b814a0ba2a9f5cb3a6459f2b6f875d03fbc#diff-d58d7599a386552bce8e4e37779fb6d7
Commenting out the RRULE_START_YEAR stuff (partially?) solves the 1970 problem. Still looking into it, but I have no idea what kind of gumnastics are necessary for generating Outlook-compatible VTIIMEZONEs.
Should be fixed by: https://github.com/libical/vzic/commit/a59b4abf32ed049d12c05db0f472575e1e9529a3
Initially I thought only the output for Europe/London was incorrect. There is a rule for transition from DST to standard time, but the other rule (which should be standard to DST) has incorrect type, name, offsets (identical) and no RRULE (shortened for clarity):
It seems many (most) other timezones have issues as well. For instance America/Los_Angeles:
DTSTART
values are in 1970, when I believe they should pick up where the previous observance rule ended.It's hard to find exactly what change caused this as many of the commits lead to versions which can't parse the tzdata included in the same commit, but this seems to be quite old.
I wasn't able to make the tests complain about it, so either I don't run the way they're supposed to, or the tests are broken as well.
I'll try to isolate this further if I find the time, but if someone more familiar with the code can get a look it might be quicker.