This section describes how dates and times are handled within Olminator in regards of timezones. The topic in itself deserves some attention if one desires to convert an .olm file as lossless as possible, of course.
As of V1.30 of Olminator, the timezone handling has been completely revised to make Olminator as reliable, as accurate and as independent of 'Microsoft Outlook for Mac as possible'. If you have converted calendar data with an Olminator version prior to 1.30 and things went through smoothly, it's extremely unlikely that you've run into any inaccuracy, but if you want to play it safe and you have your .olm file still at hand, then you may re-run the conversion with a version newer than V1.30 just to be on the future-savvy side. See below section to get a feel for what has changed.
Also, as of V2.08 of Olminator, calendar conversion has been further improved to handle the tricky situation of 'Microsoft Outlook for Mac 2011' exported .olm files. There's more information about the issues with the 2011 version below for those interested.
'Microsoft Outlook for Mac' exports date and time information consistently as UTC (Coordinated Universal Time) dates/times, i.e. in GMT timezone. This is independent of the default timezone your Microsoft Outlook client uses or the timezone you chose for a calendar appointment start or end time. That's good news as it gives us a stable and unambiguous point to start from. For emails, notes, contacts, attachments and their corresponding date/time attributes or fields (like date received of an email or date of a birthday of a contact) we don't need to do anything but pass those dates through into the converted output files: the application handling the converted files will make sure to display those UTC dates/times accordingly in your respective default timezone.
Only for calendar appointments the situation gets more tricky since as a user you want to preserve the intent (!) that the creator/modifier of a certain calendar event had when setting a start or end date/time in a specific timezone. As a example: Your airline may have sent you an appointment for your flight leaving Frankfurt International Airport (FRA) in Germany at 10:50am CET and arriving in San Francisco International Airport (SFO) in California at 2:15pm PST. 'Microsoft Outlook for Mac' will show you those timestamps together with their respective timezone. So you definitely don't want to see all calendar events' start or end times in UTC dates/times, but rather with their time slots alloted in an originating timezone. Since the .ics format for calendars doesn't allow to express all times as UTC dates/times and pass an intended "target" timezone to it so that the receiving application does the translation, we, i.e. Olminator, have to convert the timestamp accordingly from UTC to that "target" timezone. Which immediately leads to the question of what "translation rule" to use?
'Microsoft Outlook for Mac' uses some timezone references/names which are a bit "off" from the standard timezone IDs (as defined by IANA org). Olminator has been matching those Microsoft specific timezones to the "standard" ones (and continues to do so). There are two cases to differentiate:
As stated before, any dates/times are passed through "as is" in UTC time between input .olm file and the respective output formats (.mbox, .icf, .html). The big exception to this are calender dates/times.
Up to V1.21 of Olminator, Olminator has been relying on macOS system specific date/time conversion functionality to translate points in time between UTC and a specific timezone. In addition, since calendar (.ics) files require a referenced timezone definition to be embedded in the .ics file itself (RFC5445), Olminator has been including the corresponding VTIMEZONE-sections as they were exported in the .olm file by Microsoft Outlook for Mac. This approach had two shortcomings though:
From V1.30 of Olminator onwards, Olminator does not rely on macOS system specific date/time conversion functionality or Microsoft exported VTIMEZONE definitions any more. Instead, the entire timezone handling has been re-implemented based on standard IANA/"Olson DB" timezone definitions, VTIMEZONE definitions generated out of those IANA/"OlsonDB" artifacts plus the use of the "timelib" to provide rock-solid, proven conversion functionality based on that same data set. "timelib" is used by php and MongoDB, for example.
Olminator now contains the latest timezone information available (version "tzdb-2021a") and will be updated on a regular basis (there don't seem to be more than 2-3 updates to the IANA database per year worst case).
With the assumption that the UTC-based dates/times as exported by Microsoft Outlook for Mac are as close to what the creator/modifier of any calendar event was intending for a start or end date/time, Olminator now ensures the following for any date/time in a converted calendar file (.ics file):
While the .olm archives of 'Microsoft Outlook for Mac 2016' and newer versions of Outlook are well under control with the above logic if it comes to timezone handling, 'Microsoft Outlook for Mac 2011' introduced some unfortunate challenges for Calendar appointments and their timestamps (e.g. begin or end date/time). Here's the issue: 'Microsoft Outlook for Mac 2011' does not specify the timezone that the user used when creating an appointment in a IANA-compliant format, but apparently uses Microsoft-proprietary names for those timezones. It even uses locale-specific timezone names, i.e. "Europe/Berlin" if the locale of the user's Mac is in English and "Europa/Berlin" if it is in German. While this still looks manageable in this case and with a human eye, things can get nasty when considering other languages or more complicated timezone names. Olminator can not with complete accuracy or confidence map those timezone names to IANA standard timezones: there is simply not enough information available in the .olm archive (in one case the timezone in the .olm file had the name "Customized Time Zone" and that was it; not very helpful obviously).
Since Olminator v2.07 there's now the following logic for 'Microsoft Outlook for Mac 2011' timezone references: Olminator will try to derive the IANA-compliant timezone name based on some logic for exact matches plus – if an exact match can't be constructed based on that logic – try to see if there's a lexically similar timezone name with a high confidence (> 90%). If a match can be identified, Olminator will use that IANA timezone name instead of the unknown one from the archive. If no match can be found with sufficient confidence (i.e. less than 90% similarity), Olminator will use the user-defined fallback timezone (default: current system timezone) as timezone instead.
It is important to understand that Olminator will
When booking a flight from Frankfurt/Germany to San Francisco/California, some airlines send you a calendar event where the start date of your flight will be specified as time in the timezone applying to the departure location and the end date of your flight as a time in the timezone of your destination. In this example, it may be "10:55 CET" for the departure/start time and "14:55 PST" as the arrival/end time. Olminator will always convert those times correctly and the calendar event will properly show in the calendar app after import. But depending on whether Olminator was able to derive those timezone names correctly and determine the IANA standard ones, the information about "CET" and "PST" might or might not be transferred properly.
This problem with 'Microsoft Outlook for Mac 2011' does only apply to 'Microsoft Outlook for Mac 2011' and not any newer Outlook versions. And it only applies to Calendar data, not to emails, contacts or notes.
While the approach taken by Olminator as of V1.30 provides the most accurate conversion of time/dates technically possible, it still relies on Microsoft Outlook for Mac not coming up with "fancy" timezone references that are not IANA standard ones or that we haven't foreseen in Olminator's "translation" table. All current timezone names used by Microsoft Outlook for Mac have been added. If such an unlikely event occurs, Olminator handles the situation gracefully with the fallback and writes a corresponding warning/error message into the conversion log file.
So while I am pretty confident there won't be any issues with Olminator converting your calendar data (and I sleep well again since V1.30 actually), should you nevertheless experience any problems, please contact the author of Olminator and share information about the issue you ran into. We can then try to fix this. Also, if you run into issues importing (!) converted calendar data into your favorite Calendar app, please let the author know. Some apps are reported to be picky. Thanks for your support!
