locked
Using Lists Web Service - specifying XMLTZone for Recurring calendar items RRS feed

  • Question

  • This is a double posting since nobody has responded to the question in regular SP dev forums:

    Does anyone know how to find the correct value to enter into the XMLTZone field?  A in the precent past I was able to use: <timeZoneRule><standardBias>0</standardBias><additionalDaylightBias>0</additionalDaylightBias></timeZoneRule>

    for all my recurring items successfully now it seems this no longer works and I need to use: <timeZoneRule><standardBias>300</standardBias><additionalDaylightBias>-60</additionalDaylightBias><standardDate><transitionRule  month='11' day='su' weekdayOfMonth='first' /><transitionTime>2:0:0</transitionTime></standardDate><daylightDate><transitionRule  month='3' day='su' weekdayOfMonth='second' /><transitionTime>2:0:0</transitionTime></daylightDate></timeZoneRule> 

    Is there a way to know the correct value?

    The Lists Web Service Protocol specification says: in the GetList function I can get detailed information about a list it would appear from the RegionalSettings I could use the TimeZone field an excerp from the response from the GetList is below.  But the protocol spec says the TimeZone value does not indicate standard bias like it appears to but the timeZone itself - Anybody know about this?

    <RegionalSettings>

        <Language>1033</Language>

        <Locale>1033</Locale>

        <AdvanceHijri>0</AdvanceHijri>

        <CalendarType>1</CalendarType>

        <Time24>True</Time24>

        <TimeZone>300</TimeZone>

        <SortOrder>2070</SortOrder>

        <Presence>True</Presence>

      </RegionalSettings>


    Steve Schaff MicroLink, LLC
    Tuesday, October 21, 2008 3:22 PM

Answers

  • Steve,

    After review of the document we believe some documentation clarification is in order. The document is accurate but needs clarification around how Outlook rules defined all day events versus how WSS rules define all day events. For upload/download purposes an all day event starts and ends at midnight in all time zones. The updated document will likely appear on our next update cycle. In the interim please review the following information and hopefully this will resolve your immediate issue.

     

    Duration can be calculated from the EventDate and EndDate. The following algorithm MUST be used to do this:

     

    1. If the fAllDayEvent property is "1", and:

     

    a. If the fRecurrence property is "1", and:

     

    i. If the item is uploading to the protocol server, then the duration MUST be 1 minute less than 24 hours (1,439 minutes).

     

    b. Or if the fRecurrence property is "0", then:

     

    i. The duration MUST be one minute less than a positive integer multiple of 24 hours, where the multiple is the number of days the appointment occurs on.

     

    In addition, the start time of the appointment needs to be at 0hrs so that the appointment is entirely contained in a single day (if it’s one-day) or begins at the start of a day (for multi-days).  All day events begin at the beginning of a day, end at the end of a day, and last the whole day (hence the name “fAllDayEvent” and the duration rules).

     

    The following schema is from a successful upload and you will note that the XMLTZone is the same as in the original question.

    <Method ID="0" Cmd="New">

      <Field Name="ID">New</Field>

      <Field Name="Title">allday recur</Field>

      <Field Name="Description"><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META NAME="Generator" CONTENT="MS Exchange Server version 08.00.0681.000"> <TITLE></TITLE> </HEAD> <BODY> <!-- Converted from text/rtf format --> <DIV DIR=LTR><SPAN LANG="en-us"></SPAN></DIV> </BODY> </HTML></Field>

      <Field Name="Location" />

      <Field Name="fAllDayEvent">1</Field>

      <Field Name="RecurrenceData"><recurrence><rule><firstDayOfWeek>su</firstDayOfWeek><repeat><daily dayFrequency='1' /></repeat><repeatInstances>10</repeatInstances></rule></recurrence></Field>

      <Field Name="XMLTZone"><timeZoneRule><standardBias>0</standardBias><additionalDaylightBias>0</additionalDaylightBias></timeZoneRule></Field>

      <Field Name="UID">{508BBC71-827D-4DF7-89A2-843A8B81CBA7}</Field>

      <Field Name="EventDate">2008-10-27T00:00:00Z</Field>

      <Field Name="EndDate">2008-11-04T23:59:00Z</Field>

      <Field Name="fRecurrence">-1</Field>

      <Field Name="EventType">1</Field>

      <Field Name="MetaInfo" Property="FollowUp" />

      <Field Name="MetaInfo" Property="Priority">0</Field>

      <Field Name="MetaInfo" Property="IntendedBusyStatus">-1</Field>

      <Field Name="MetaInfo" Property="BusyStatus">0</Field>

      <Field Name="MetaInfo" Property="Categories" />

      <Field Name="MetaInfo" Property="ReplicationID">{B05197B0-F587-4A5A-9B71-A69AAA1D1792}</Field>

      <Field Name="MetaInfo" Property="vti_versionhistory">a00931526b56bc458b37044099543579:1</Field>


    I hope this helps clear things up.

    Steve Smegner
    Application Development Consulting Group

    • Proposed as answer by Steve Smegner Friday, November 7, 2008 9:03 AM
    • Marked as answer by SSchaff Friday, November 7, 2008 12:50 PM
    Friday, November 7, 2008 9:03 AM
  • Steve,
    The documents have multiple updates which will be released on the next documentation update. I will pass along your comments but I believe this section has already been updated.

    Steve Smegner
    Application Development Consulting Group
    • Proposed as answer by Steve Smegner Friday, November 21, 2008 5:06 PM
    • Marked as answer by SSchaff Friday, November 21, 2008 5:34 PM
    Friday, November 21, 2008 5:05 PM
  • Steve,
        Actually my issues with the List Web Service are solved for the moment.  I actually ended up contacting product support using a partner support case to find my solution and posted the code here.  Actually two issues were uncovered during the support case - first the solution to create the TimeZoneXML from the client proved relatively simple.  Second there exists a bug in SharePoint according to my support engineer that will be resolved in the next service pack - creating a recurring item using the List Web Service or using the SP object model the user/dev must provide what was coined as the "ideal" end date.  I have created and submitted code that will calculate the "ideal" end date for my application however my support engineer told me without studying my code, it may not work for calculations across a leap year correctly.  He attempted many times to create various types of recurring items via the List Web Service and using the object model and FAILED.  After his attempts he reported the results to me and the product group for SharePoint.  For the time being I am seeing this work so until the bug is resolved I have no choice but to go with what I have created.

    Thank you for following up.

    Steve Schaff
    Steve Schaff MicroLink, LLC
    • Marked as answer by SSchaff Wednesday, January 21, 2009 1:20 PM
    Wednesday, January 21, 2009 1:20 PM
  • Steve,
    I am glad to hear it. You actually took the proper route. Product support is done through standard channels. Open Specification document support is managed here. However if you feel the document is wrong or needs clarifying then start here. If it ends up being a product support issue then we will move to the standard support channels.

    Have a good day. If you need anything else let us know.

    Steve Smegner
    Application Development Consulting Group
    • Marked as answer by Steve Smegner Wednesday, January 21, 2009 11:44 PM
    Wednesday, January 21, 2009 11:43 PM

All replies

  •  Steve,

    Thanks for your post.  We will review your question and get back to your shortly.  While we research this issue, have you taken a look at MS-OUTSPS section 2.2.4.6 TimeZoneRule to assist you with your issue?  Let us know if this helps solve your problem.

    Richard Guthrie
    Open Protocols Team
    Wednesday, October 22, 2008 6:51 PM
  • Yes I have seen MS-OUTSPS section 2.2.4.6 - I actually just found this today but this not withstanding - I write all values in UTC by <DateInUtc>TRUE</DateInUTC> - and convertting all eventDates start & end to UniversalTime before writng except for AllDayEvents.  Since I write all list items in UTC - Can you tell me why this:  <timeZoneRule><standardBias>0</standardBias><additionalDaylightBias>0</additionalDaylightBias></timeZoneRule>
    no longer works?

    At present even though I specify event dates in utc I must use the timeZoneRule:  <timeZoneRule><standardBias>300</standardBias><additionalDaylightBias>-60</additionalDaylightBias><standardDate><transitionRule  month='11' day='su' weekdayOfMonth='first' /><transitionTime>2:0:0</transitionTime></standardDate><daylightDate><transitionRule  month='3' day='su' weekdayOfMonth='second' /><transitionTime>2:0:0</transitionTime></daylightDate></timeZoneRule>

    This seems to contradict MS-OUTSPS section 3.2.4.2.2 on pg 60 "

    XMLTZone: If EventType is "1", then this property MUST contain a valid TimeZoneXML (section 2.2.4.7). The TimeZoneXML defines the time zone the event uses. If fRecurrence is FALSE, then this property SHOULD be ignored and can be empty. "

    Since all of my records are written in UTC this seems contradictory - does it not?


    Steve Schaff MicroLink, LLC
    Wednesday, October 22, 2008 7:15 PM
  • Steve,
    I am researching this internally. I will have an update here as soon as my research is complete.

    Steve Smegner
    Application Development Consulting Group
    Tuesday, October 28, 2008 7:14 AM
  • Steve,

    After review of the document we believe some documentation clarification is in order. The document is accurate but needs clarification around how Outlook rules defined all day events versus how WSS rules define all day events. For upload/download purposes an all day event starts and ends at midnight in all time zones. The updated document will likely appear on our next update cycle. In the interim please review the following information and hopefully this will resolve your immediate issue.

     

    Duration can be calculated from the EventDate and EndDate. The following algorithm MUST be used to do this:

     

    1. If the fAllDayEvent property is "1", and:

     

    a. If the fRecurrence property is "1", and:

     

    i. If the item is uploading to the protocol server, then the duration MUST be 1 minute less than 24 hours (1,439 minutes).

     

    b. Or if the fRecurrence property is "0", then:

     

    i. The duration MUST be one minute less than a positive integer multiple of 24 hours, where the multiple is the number of days the appointment occurs on.

     

    In addition, the start time of the appointment needs to be at 0hrs so that the appointment is entirely contained in a single day (if it’s one-day) or begins at the start of a day (for multi-days).  All day events begin at the beginning of a day, end at the end of a day, and last the whole day (hence the name “fAllDayEvent” and the duration rules).

     

    The following schema is from a successful upload and you will note that the XMLTZone is the same as in the original question.

    <Method ID="0" Cmd="New">

      <Field Name="ID">New</Field>

      <Field Name="Title">allday recur</Field>

      <Field Name="Description"><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META NAME="Generator" CONTENT="MS Exchange Server version 08.00.0681.000"> <TITLE></TITLE> </HEAD> <BODY> <!-- Converted from text/rtf format --> <DIV DIR=LTR><SPAN LANG="en-us"></SPAN></DIV> </BODY> </HTML></Field>

      <Field Name="Location" />

      <Field Name="fAllDayEvent">1</Field>

      <Field Name="RecurrenceData"><recurrence><rule><firstDayOfWeek>su</firstDayOfWeek><repeat><daily dayFrequency='1' /></repeat><repeatInstances>10</repeatInstances></rule></recurrence></Field>

      <Field Name="XMLTZone"><timeZoneRule><standardBias>0</standardBias><additionalDaylightBias>0</additionalDaylightBias></timeZoneRule></Field>

      <Field Name="UID">{508BBC71-827D-4DF7-89A2-843A8B81CBA7}</Field>

      <Field Name="EventDate">2008-10-27T00:00:00Z</Field>

      <Field Name="EndDate">2008-11-04T23:59:00Z</Field>

      <Field Name="fRecurrence">-1</Field>

      <Field Name="EventType">1</Field>

      <Field Name="MetaInfo" Property="FollowUp" />

      <Field Name="MetaInfo" Property="Priority">0</Field>

      <Field Name="MetaInfo" Property="IntendedBusyStatus">-1</Field>

      <Field Name="MetaInfo" Property="BusyStatus">0</Field>

      <Field Name="MetaInfo" Property="Categories" />

      <Field Name="MetaInfo" Property="ReplicationID">{B05197B0-F587-4A5A-9B71-A69AAA1D1792}</Field>

      <Field Name="MetaInfo" Property="vti_versionhistory">a00931526b56bc458b37044099543579:1</Field>


    I hope this helps clear things up.

    Steve Smegner
    Application Development Consulting Group

    • Proposed as answer by Steve Smegner Friday, November 7, 2008 9:03 AM
    • Marked as answer by SSchaff Friday, November 7, 2008 12:50 PM
    Friday, November 7, 2008 9:03 AM
  • Please confirm if possible the following:

    I have noticed that if uploading recurring items in UTC that the Lists web service (server side of the protocol), the recurrence is calculated without convertting to the local time zone of the server, then stored in UTC format.

    An illustration of this is if an UpdateListItems batch is sent including a new list item defined as a yearly recurring item on the last monday of November 2008 at 7:00 - 7:30 pm EST beginning 24 Nov 2008.  If the item is written in UTC the start time is convertted to 12am - 12:30 am 25 Nov 2008 UTC and the recurrence calculation does not select 24 Nov 2008 as the first occurrence of the pattern.  Is this true?

    If this is true this explains in detail why its might be important to write items in the local time zone versus using UTC, however the client application must know the correct/valid XMLTZone and time zone code for the client performing the UpdateListItems web service request.  Is there any way to request the XMLTZone value for a particular time zone?  Is there any way to retrieve the client time zone - code i.e. 10 for EST that will match SP's timezone codes?
    Steve Schaff MicroLink, LLC
    Monday, November 17, 2008 11:25 PM
  • Sorry for multiple responses - so if I've seen and read here correctly - it is a limitation of SP UI and lists web service that niether programatically or via the UI a user can not create a recurring multi-day event (of type 1).  Can I suggest pointing this out directly instead of having the reader infer this?
    Steve Schaff MicroLink, LLC
    • Marked as answer by SSchaff Friday, November 21, 2008 5:33 PM
    • Unmarked as answer by SSchaff Friday, November 21, 2008 5:34 PM
    Monday, November 17, 2008 11:39 PM
  • Steve,
    The documents have multiple updates which will be released on the next documentation update. I will pass along your comments but I believe this section has already been updated.

    Steve Smegner
    Application Development Consulting Group
    • Proposed as answer by Steve Smegner Friday, November 21, 2008 5:06 PM
    • Marked as answer by SSchaff Friday, November 21, 2008 5:34 PM
    Friday, November 21, 2008 5:05 PM
  • Steve 
        Awesome thanks - I think I've realized a couple of things since my initial posts thanks to you and other support folks efforts NavDeep Madan partner support case - with regard to this topic - Lists web service - UpdateListItems function - I hope this post helps someone else.  Please correct me if any of my statements are incorrect.

    1st - client aplpications really need to send the appropriate XMLTZone for each recurring event sent - so the problem becomes how do you do it?

    2nd - client applications really need to send an 'ideal' end date for recurring events (for some patterns you can get away with picking some date in the distant future at random) - again the problem is how do you do it?

    3rd - TimeZone - essentially don't use it - note the following excerp From the Lists Web Service Client Protocol Specification:

     

    TimeZone: If fRecurrence is TRUE, this property SHOULD contain an integer index into a list of time zones. Where this list exists and how to access it is an implementation detail of the protocol server. Protocol servers SHOULD set a number in this value, but can leave it empty. Protocol clients SHOULD remember whatever number the protocol server provides here. Protocol clients SHOULD set the recurrence TimeZone integer on exceptions to a recurrence (section 3.2.1.1.3) when protocol clients update exception items. Protocol clients SHOULD NOT use TimeZone for any other purpose. Instead, protocol clients SHOULD use XMLTZone because this approach is more extensible and flexible.

    The thing is I've can't make the SP Lists web service spit back the TimeZone field - so the moral to this story - if the server ever spits it back in response to new or update commands use it on updates but otherwise use XMLTZone - cuz it's better, more flexible ...

    4th - AllDayEvents recurring or not, event date and end date values must be written in UTC timezone. If this AllDayEvent item is recurring or is an exception to a recurring item you must send the appropriate UTC XMLTZone value - I hard code this.

    So here's my answer to my question how do you do it #1
    other classes use the class below:

                    TimeZone tz = new TimeZone();
                    string strXMLTZone = tz.GetXMLTZone(System.TimeZone.CurrentTimeZone.StandardName);

           //     this allows a client to create the appropriate XMLTZone for their current TimeZone

        class TimeZone
        {
            [DllImport("kernel32.dll", CharSet = CharSet.Auto, ExactSpelling = false)]
            private static extern int SystemTimeToTzSpecificLocalTime(ref
    TIME_ZONE_INFORMATION lpTimeZone, ref SYSTEMTIME lpUniversalTIme, out
    SYSTEMTIME lpLocalTime);

            [DllImport("kernel32.dll", CharSet = CharSet.Auto, ExactSpelling = false)]
            private static extern int TzSpecificLocalTimeToSystemTime(ref
    TIME_ZONE_INFORMATION lpTimeZone, ref SYSTEMTIME lpLocalTime, out SYSTEMTIME
            lpUniversalTIme);

            [StructLayout(LayoutKind.Sequential)]
            private struct SYSTEMTIME
            {
                public ushort wYear;
                public ushort wMonth;
                public ushort wDayOfWeek;
                public ushort wDay;
                public ushort wHour;
                public ushort wMinute;
                public ushort wSecond;
                public ushort wMilliseconds;
            }

            //Registry time zone format. See KB article Q115231
            [StructLayout(LayoutKind.Sequential)]
            private struct REG_TIME_ZONE_INFORMATION
            {
                public int Bias;
                public int StandardBias;
                public int DaylightBias;
                public SYSTEMTIME StandardDate;
                public SYSTEMTIME DaylightDate;
            }

            [StructLayout(LayoutKind.Sequential, CharSet = CharSet.Unicode)]
            private struct TIME_ZONE_INFORMATION
            {
                public int Bias;
                [MarshalAs(UnmanagedType.ByValTStr, SizeConst = 32)]
                public string StandardName;
                public SYSTEMTIME StandardDate;
                public int StandardBias;
                [MarshalAs(UnmanagedType.ByValTStr, SizeConst = 32)]
                public string DaylightName;
                public SYSTEMTIME DaylightDate;
                public int DaylightBias;
                public int Index;
            }

            private static List<TIME_ZONE_INFORMATION> GetTimeZones()
            {
                List<TIME_ZONE_INFORMATION> list = new List<TIME_ZONE_INFORMATION>();
                RegistryKey key =
                Registry.LocalMachine.OpenSubKey(@"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones");
                if (key == null)
                    return list;

                string[] subKeyNames = key.GetSubKeyNames();
                foreach (string subKeyName in subKeyNames)
                {
                    RegistryKey subKey = key.OpenSubKey(subKeyName);
                    if (subKey != null)
                    {
                        object value = subKey.GetValue("TZI");
                        if (value != null)
                        {
                            int length =
                            Marshal.SizeOf(typeof(REG_TIME_ZONE_INFORMATION));
                            IntPtr p = Marshal.AllocHGlobal(length);
                            Marshal.Copy((byte[])value, 0, p, length);
                            REG_TIME_ZONE_INFORMATION rtzi = (REG_TIME_ZONE_INFORMATION)Marshal.PtrToStructure(p, typeof(REG_TIME_ZONE_INFORMATION));
                            Marshal.FreeHGlobal(p);

                            TIME_ZONE_INFORMATION tzi = new TIME_ZONE_INFORMATION();
                            tzi.Bias = rtzi.Bias;
                            tzi.DaylightBias = rtzi.DaylightBias;
                            tzi.StandardBias = rtzi.StandardBias;
                            tzi.DaylightDate = rtzi.DaylightDate;
                            tzi.StandardDate = rtzi.StandardDate;
                            tzi.DaylightName = (string)subKey.GetValue("Dlt", "");
                            tzi.StandardName = (string)subKey.GetValue("Std", "");
                            tzi.Index = (int)subKey.GetValue("Index", 0);
                            list.Add(tzi);
                        }
                        subKey.Close();
                    }
                }
                key.Close();
                return list;
            }

            public string GetXMLTZone(string stdName)
            {
                string XMLTZone = string.Empty;
                List<TIME_ZONE_INFORMATION> tZoneList = GetTimeZones();
                foreach(TIME_ZONE_INFORMATION tZone in tZoneList)
                {
                    if (tZone.StandardName == stdName)
                    {
                        XMLTZone = "<timeZoneRule><standardBias>" + tZone.Bias.ToString() + "</standardBias>";
                        XMLTZone += "<additionalDayLightBias>" + tZone.DaylightBias.ToString() + "</additionalDayLightBias>";
                        if (tZone.StandardDate.wMonth != 0)
                            XMLTZone += "<standardDate>" + GetTransitionRule(tZone.StandardDate) + "</standardDate>";
                        if (tZone.DaylightDate.wMonth != 0)
                            XMLTZone += "<daylightDate>" + GetTransitionRule(tZone.DaylightDate) + "</daylightDate>";
                        XMLTZone += "</timeZoneRule>";
                        break;
                    }
                }
                return XMLTZone;
            }
           
            private string GetTransitionRule(SYSTEMTIME sysTime)
            {
                string transRule = "<transitionRule month='" + sysTime.wMonth.ToString() + "' day='";
                    transRule += GetDayOfWeek(sysTime.wDayOfWeek) + "' weekdayOfMonth='";
                    DateTime dtDayLight = new DateTime(sysTime.wYear == 0 ? DateTime.Now.Year : sysTime.wYear,
                                                        sysTime.wMonth,
                                                        sysTime.wDay,
                                                        sysTime.wHour,
                                                        sysTime.wMinute,
                                                        sysTime.wSecond);
                    WeekIndex wIdx;
                    try
                    {
                        wIdx = GetWeekIndex(dtDayLight);
                        transRule += wIdx.ToString() + "' /><transitionTime>";
                        transRule += dtDayLight.ToString("H:m:s") + "</transitionTime>";
                    }
                    catch
                    { }
                return transRule;
            }

            private string GetDayOfWeek(ushort wDayOfWeek)
            {
                switch(wDayOfWeek)
                {
                    case 0:
                        return "su";
                    case 1:
                        return "mo";
                    case 2:
                        return "tu";
                    case 3:
                        return "we";
                    case 4:
                        return "th";
                    case 5:
                        return "fr";
                    case 6:
                        return "sa";
                    default:
                        return "";
                }
            }
            public enum WeekIndex
            {
                First = 1,
                Second = 2,
                Third = 3,
                Fourth = 4,
                Last = 5
            }



            public static WeekIndex GetWeekIndex(DateTime inputDate)
            {
                int weekNo = 0;
                DateTime date = (new DateTime(inputDate.Year, inputDate.Month, 1)).AddDays(-1);
                DateTime lastday = (new DateTime(inputDate.Year, inputDate.Month, 1)).AddMonths(1).AddDays(-1);
                for (int i = 1; i <= lastday.Day; i++)
                {
                    DateTime day = date.AddDays(i);
                    if (day > inputDate)
                        break;
                    if (day.DayOfWeek == System.Globalization.CultureInfo.CurrentUICulture.DateTimeFormat.FirstDayOfWeek || weekNo == 0)
                        weekNo++;
                }
                return (WeekIndex)weekNo;
            }

            public static DateTime GetSpecificDate(int year, int month, WeekIndex weekIndex, DayOfWeek weekDay)
            {
                DateTime date = (new DateTime(year, month, 1)).AddDays(-1); //last day of previous month
                DateTime lastday = (new DateTime(year, month, 1)).AddMonths(1).AddDays(-1);
                for (int i = 1; i <= lastday.Day; i++)
                {
                    DateTime day = date.AddDays(i);
                    if (day.DayOfWeek == weekDay && GetWeekIndex(day) == weekIndex)
                        return day;
                }
                throw new ArgumentOutOfRangeException("weekIndex", "Can't find date with provided arguments!");
            }


        }




    Steve Schaff MicroLink, LLC
    Friday, November 21, 2008 5:32 PM
  • Hey Steve,
    It seems my last post has vanished and I never got a thread alert. How are you doing with the timezone work? The sample code looks good. Are things working as you expect them to work?

    Steve Smegner
    Application Development Consulting Group
    • Proposed as answer by Steve Smegner Wednesday, January 21, 2009 5:00 AM
    Wednesday, January 21, 2009 5:00 AM
  • Steve,
        Actually my issues with the List Web Service are solved for the moment.  I actually ended up contacting product support using a partner support case to find my solution and posted the code here.  Actually two issues were uncovered during the support case - first the solution to create the TimeZoneXML from the client proved relatively simple.  Second there exists a bug in SharePoint according to my support engineer that will be resolved in the next service pack - creating a recurring item using the List Web Service or using the SP object model the user/dev must provide what was coined as the "ideal" end date.  I have created and submitted code that will calculate the "ideal" end date for my application however my support engineer told me without studying my code, it may not work for calculations across a leap year correctly.  He attempted many times to create various types of recurring items via the List Web Service and using the object model and FAILED.  After his attempts he reported the results to me and the product group for SharePoint.  For the time being I am seeing this work so until the bug is resolved I have no choice but to go with what I have created.

    Thank you for following up.

    Steve Schaff
    Steve Schaff MicroLink, LLC
    • Marked as answer by SSchaff Wednesday, January 21, 2009 1:20 PM
    Wednesday, January 21, 2009 1:20 PM
  • Steve,
    I am glad to hear it. You actually took the proper route. Product support is done through standard channels. Open Specification document support is managed here. However if you feel the document is wrong or needs clarifying then start here. If it ends up being a product support issue then we will move to the standard support channels.

    Have a good day. If you need anything else let us know.

    Steve Smegner
    Application Development Consulting Group
    • Marked as answer by Steve Smegner Wednesday, January 21, 2009 11:44 PM
    Wednesday, January 21, 2009 11:43 PM