Problem transferring MS Works Calendar

RickL1 · 21 May 2014

Hello,
I am helping a friend migrate from Windows XP with old applications to a new computer Windows 7 Pro 32 bit. I am trying to make the transition simple for him, so transferring as much of the old applications as possible. The one that is kicking my behind right now is the Calendar in Microsoft Works v9. Installation of MS Works v9 on the new computer did not present any problems, so both computers have the same version.

What should have worked is to simply copy the mswkscal.wcd file from old computer to new computer. It partially worked, but not well enough to be useable. The old computer has calendar event items that go back to 2001, so there is a lot of sentimental and historical information to be preserved. There were 3 significant things that I observed.
1. The name on the calendar tab started out as "My Calendar" on both computers, but changing it did not solve any problems.
2. There are no events displayed in the calendar view screen, none at all. When I opened the "Reminders" view then there were several items listed for the current date, just like they should be shown. So the events are there somewhere, but cannot be seen. When I opened one of those items on the Reminder list, it did have the proper Recurrence information.
3. I tried an export on the old computer (both as .vcs and .ics) to import on the new computer and again ran into problems. The import on the new computer gave an error that the file was not formatted correctly (I later decided maybe the file is too big). When I opened the exported files (using Notepad) I noticed that there was not any information about Recurrence (such as a birthday happening every year), so if I can get the import to work it would still be only part of the needed Event Detail information. For an interesting twist I tried the export to html (limited to 24 months, also created a matching .vcs file) and the import accepted it, but again there was no Recurrence information.

So the first of my questions is, is there a special trick to getting the mswkscal.wcd file to be properly accepted on the new computer, as this seems to be the only way to get the Recurrence information transferred?

My second question is, if my friend decides to switch from the Works Calendar to the Outlook 2013 Calendar, how do I get the Recurrence information to transfer?

It really shouldn't be this hard.

Kari · 21 May 2014

I do not know Ms Works too well but I believe it can export to an ICS file (*.ics). The Outlook.com calendar (former Windows Live Calendar) at https://calendar.live.com supports importing ICS files, so I would at least try that first and then see and decide if it would be the right time to let Works retire. To use Outlook.com calendar you need a Microsoft Account (Hotmail, Live, MSN or Outlook.com email).

Step 1: Export Works calendar as *.ics file
Step 2: Go to https://calendar.live.com, click Import:
Step 3: Select Import into a new calendar, browse to your *.ics file, click Import

Kari

RickL1 · 27 May 2014

Here is the update report on how I worked my way through this mess.

The problems started in Microsoft Works v9. What my friend had done is to enter most of the items in the calendar as All-Day times (Birthdays and Anniversaries), so the New Year's Day holiday item had a start time of 1/1/2001 00:00 (12am) and a end time of 1/2/2001 00:00 (12am). To be more technically accurate, the times are stored for the CUT time zone, so it is actually 1/1/2001 07:00 to 1/2/2001 07:00. The time zone that I am in is USA Mountain = CUT-7 for Standard Time and CUT-6 for Daylight-Savings Time. The Time Zone is very important, and, as I painfully discovered, the Daylight-Savings Time adjustment (and lack thereof) causes major problems.

I mentioned in the first post that just transferring the mswkscal.wcd file did not give a useable calendar, and doing an Export then Import failed completely for both the .vcs and .ics file types. So here is a very interesting twist. When I did an Export to html type I got both a .htm and a .vcs files, and, to add another mystery, that second .vcs file Imported without any errors. So I looked for the difference, which seems to be in the DTSTAMP: field where the first .vcs got the date and time that I created the Export file, and the Export to html .vcs has the fieldname without any value. Another oddity is that for the Export to .vcs and .ics you can specify any date range, however the Export to html has a maximum date range limit of 24 months. On the old computer I also attempted the Export to .csv, but that failed with a program error, so I'll never know if that type of file would work any better (not likely).

Now that I had a file that could be Imported, all should have been well, but it wasn't. I mentioned above that the Export files did not contain any Recurrence information, so in a Export file covering 12 months a item that Repeats monthly will be 12 separate items. The Recurrence was decided to be a manageable problem by manually adding it for just the current year (2014) items. My friend wanted to eventually move from Works to Outlook, so I repeated the Import tests in Outlook and found the same results. We decided to avoid having to re-enter the Recurrence information twice and just make the move to Outlook Calendar now.

That left the next problem which is caused by Daylight-Savings Time. We noticed that in the current month (May) the All-Day items looked perfect on the calendar, and were quite happy with that. When I looked at some other months, well the happiness went away. Basically the first two and last two months had the All-Day items spread across two days. They were showing a start time of 11:00pm and a end time of 11:00pm. The nastiness of Daylight-Savings Time strikes again. The source of this problem is in the Export, which apparently totally disregards the Daylight-Savings Time shift. The Export simply looked at the current Time Zone (Daylight-Savings Time active) and applied that to the entire file, which in this test was only 2014. This was pretty obvious when looking inside the Export as html .vcs file. Here are two samples that show the difference in the lack of a adjustment for Daylight-Savings Time.
BEGIN:VEVENT
DTSTAMP:
UID:4A4A77EB-AA2A-43A4-8608-F01D16108A89
DTSTART:20140101T060000Z
DTEND:20140102T060000Z
SUMMARY;ENCODING=QUOTED-PRINTABLE:New Years Day
CATEGORIES;ENCODING=QUOTED-PRINTABLE:Holiday
END:VEVENT

BEGIN:VEVENT
DTSTAMP:
UID:54327FD2-A727-4BD9-8625-E73DB69F2B30
DTSTART:20140521T060000Z
DTEND:20140522T060000Z
SUMMARY;ENCODING=QUOTED-PRINTABLE:PAY BILLS
CATEGORIES;ENCODING=QUOTED-PRINTABLE:Not Categorized
BEGIN:VALARM
TRIGGER:-PT86400S
ACTION: DISPLAY
DESCRIPTION:Reminder
END:VALARM
END:VEVENT

The item for New Year's Day should have had
DTSTART:20140101T070000Z
DTEND:20140102T070000Z
if the Export had properly adjusted for that item being in Standard Time. The Pay Bills item had the correct time for being in Daylight-Savings Time.

The problem has now been identified, and understood, so what is the solution? We decided upon manually adjusting about 4 months worth of the 2014 items that had already been imported. For the 2001 - 2013 items we needed a better solution. One solution would be to live within the limitations of the Export such that I would have to do separate Exports for Standard and Daylight-Savings Time date ranges along with changing the computer system date to move in and out of Daylight-Savings Time, and this is probably the most accurate solution. This is further complicated by the fact that in the USA the Daylight-Savings Time rules have been changed during the date range I am working with. That seemed like a lot of work, and I had already created the Export as html files in 2 year increments. I decided to adjust those Exported files so that the start time would be 07:00am and the end time would be 05:00am and that way it would not matter which way the Daylight-Savings Time problem would shift and the item would stay within the correct date. I worked up a DOS Batch file to do that, and then imported the adjusted files. If you have been able to actually follow all of this, then you have probably realized that I have not adjusted the time for items that are not All-Day times, and that is why doing the Exports according to the Time Zone changes is the most accurate method to deal with the problem. We discussed the situation of some of those items having an incorrect time and decided that the inaccuracy was not important for my friend.

[edit] The solution for dividing up the Export date ranges according to Daylight-Savings Time status may also require that you adjust the System Date accordingly for the Importing the files. This is something that you would have to test for your own situation, so be ready to restore your calendar to a pre-import condition.

Whew!

Qeter22sep2016 · 21 Sep 2016

This is 'easily' found and easily solved. A .vcs import into Works v9 Calendar can be at most 1485 entries, and at exactly 1486 entries or more it fails. The limit corresponds to roughly 10'340 lines in the .vcs file, which is a simple text file, every entry is approximately 7 lines. I did split my large file into chunks of 10'000 lines at calendar entries (BEGIN:vEvent and END:vEvent lines), and succeeded.

MoxieMomma · 21 Sep 2016

Hello and welcome, @Qeter22sep2016:

The last reply in this thread was back in May 2014.

It's likely that neither the OP nor the other members may be following it now.

But thanks for your helpful suggestion.

Cheers,
MM

Qeter22sep2016 · 21 Sep 2016

I know, but I had the issue today, and OP was the only one mentioning the problem at all. I found the exact magic reason for it (by varying several parameters, mostly in the content and the file size area).
I posted my suggested solution not for OP, but for the next person to run into the problem.