Generate the text file, and then post process the file using some sort of external technology.ī. To avoid confusion, any existing hard returns from within the source data are converted to a “vertical tab” character (ASCII 11).īut we’re not going to let a puny ASCII character defeat us, are we? (Yes, I know, these are Unicode, not ASCII, codes… but the values are the same either way, and it’s easier to refer to ASCII codes than Unicode “code points”.)īroadly speaking, there are two different approaches we can take to solve this problem:Ī. When you export to a text file, FileMaker uses ASCII 13 as the record delimiter, i.e, puts a hard return between the data from each record. While inconvenient, this makes sense if you think about it. …a text file with three lines, each a mile long. We simply export our found set of appointments to a text file with an “ics” extension and declare victory, right? Well, not quite. Let’s reduce our found set to three records, go into preview mode and see how that calc evaluates.
How to import ics to outlook 2016 mac update#
The UID is very important, because if you import the same appointments more than once, the calendar will be smart enough to update existing entries where there is a matching UID, rather than allowing them to appear twice. But as long as it’s unique within your calendar, you’ll be fine. Ideally it’s some form of “ UUID” which means that heroic measures have been taken to attempt to guarantee its absolute uniqueness.
How to import ics to outlook 2016 mac serial#
Since I don’t care about that, I’m just making it the same as DTSTART.Īnd finally we come to the UID entry, which is simply a unique serial number. During Daylight Savings Time, the offset value would be -7, but we’re on Standard Time now, so the correct value is -8.Ĭlearly DTSTART is the beginning time for the appointment, and DTEND is the ending time, but what’s DTSTAMP? That is the “creation time” of the appointment, and apparently is required.
So the first row in our appointments table, with a starting time of 10:00 Am, will be converted to the UTC equivalent of 180000 when we export it, because the database is located in the Pacific time zone, which is 8 hours offset, i.e., UTC-08.
One important observation about the time portion: it is represented as UTC time, not local time. First we have the date formatted as YYYYMMDD, followed by a T, followed by the time in 24hour format, hhmmss, followed by a Z. The BEGIN, SUMMARY and END entries seem self-explanatory, but what’s going on with those “DT” entries? Well, as you’ve probably guessed, they’re timestamps. Let’s take a closer look at the body section. Next we have one or more body entries that look like this:Īnd at the very end of the file comes the footer, which looks like this: PRODID:-//FileMaker Pro//NONSGML yourSolutionNameHere//EN At the beginning of the file is the header, which looks like this: We’re going to create an “ics” file, which is a text file with three distinct elements. Let’s start with a basic table of appointments, like this. I don’t claim that what follows is in any way authoritative, just that it works… and not just with iCal, but with Outlook, Google Calendar and any other program that recognizes the iCalendar format. I’d never done this before, but I did a bit of reading on Wikipedia and elsewhere, and it turns out to be fairly straight forward.
The other day I needed to export some appointments from FileMaker to iCal.