397727 - Incorrect DateTime format for Calendar request.

Status: RESOLVED FIXED

(Calendar :: Provider: GData, defect)

Description

[Andrew Tierney]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7; .NET CLR 2.0.50727) Gecko/20070914 Firefox/2.0.0.7
Build Identifier: Timezone issues with toRFC3389 routine

In Australia I was only receiving in 'DAY VIEW' mode events after 10am.

The problem appears to be in the following routine:

function toRFC3339(aDateTime) {

    if (!aDateTime) {
        return "";
    }

    var tzoffset_hr = Math.floor(aDateTime.timezoneOffset / 3600);

    var tzoffset_mn = ((aDateTime.timezoneOffset / 3600).toFixed(2) -
                       tzoffset_hr) * 60;

    var str = aDateTime.year + "-" +
        ("00" + (aDateTime.month + 1)).substr(-2) +  "-" +
        ("00" + aDateTime.day).substr(-2);

    // Time and Timezone extension
    // AJT - PATCH to force Timezone ALWAYS
    //if (!aDateTime.isDate) {
        str += "T" +
               ("00" + aDateTime.hour).substr(-2) + ":" +
               ("00" + aDateTime.minute).substr(-2) + ":" +
               ("00" + aDateTime.second).substr(-2);
        if (aDateTime.timezoneOffset != 0) {
            str += (tzoffset_hr < 0 ? "-" : "+") +
                   ("00" + Math.abs(tzoffset_hr)).substr(-2) + ":" +
                   ("00" + Math.abs(tzoffset_mn)).substr(-2);
        } else if (aDateTime.timezone == "floating") {
            // RFC3339 Section 4.3 Unknown Local Offset Convention
            str += "-00:00";
        } else {
            // ZULU Time, according to ISO8601's timezone-offset
            str += "Z";
        }
    // AJT - PATCH to force Timezone ALWAYS
    //}
    return str;
}

I have patched the routine above so it works in Australia.

The routine would get a true for isDate and leave the date in a format as
follows:

2007-09-26

No T:...+10....etc etc..

The routine does have dates passed where isDate is FALSE, but for DAYVIEW
it appears to be always true. Hence the formatting was being skipped.

The above code is my hack so I can use the calendar in Australia.


Reproducible: Always

Steps to Reproduce:
1. Be in an Australian Timezone
2. Have an event before 10am
3. Click on the DayView.. No events will be shown before 10am.
Actual Results:  
Missing events from dayview.

Expected Results:  
events prior to 10am in dayview.

Attached is the fix/hack/patch to resolve the problem.

Comment 1

[Philipp Kewisch [:Fallen][📱📆]]

Which version of the gdata provider are you using? Is the timezone you are in a half-hour timezone? There was a fix for half hour timezones in bug 388735, which is in the CVS version of the gdata provider.

I havent tried to reproduce, but I don't see how this fixes this bug. According to rfc3339, dates should not have a timezone. If I understand what you are doing correctly, you force a timezone also for dates.

Comment 2

[Andrew Tierney]

I'm using the nightly build (gdata-provider-2007-09-25-14.xpi). (shows as 0.2.2 when installed) with lightning 0.7pre (nightly build also).

I'm in Sydney Australia +10hr.

As you say the rfc3339 may state no need for timezone.. 

BUT..

The Google API (http://code.google.com/apis/calendar/reference.html) states:

start-min  	Earliest event start time to match. If not specified, default is 1970-01-01.  	

    * Use the RFC 3339 timestamp format. For example: 2005-08-09T10:57:00-08:00.
    * The lower bound is inclusive, whereas the upper bound is exclusive.
    * Events that overlap the range are included.

start-max 	Latest event start time to match. If not specified, default is 2031-01-01.

Now the toRFC3339 routine in calGoogleUtils.js only returns yyyy-mm-dd instead of yyyy-mm-dd-THH:MM:SS-XX:YY due to the (!aDateTime.isDate) check.

The routine below builds the request string.

    getItems: function cGS_getItems(aCalendar,
                                    aCount,
                                    aRangeStart,
                                    aRangeEnd,
                                    aItemReturnOccurrences,
                                    aResponseListener,
                                    aExtraData) {

        var rfcRangeStart = toRFC3339(aRangeStart);
        var rfcRangeEnd = toRFC3339(aRangeEnd);

        var request = new calGoogleRequest(this);

        request.type = request.GET;
        request.uri = aCalendar.fullUri.spec;
        request.setResponseListener(aCalendar, aResponseListener);
        request.extraData = aExtraData;
        request.calendar = aCalendar;

        // Request Parameters
        request.addQueryParameter("max-results",
                                  aCount ? aCount : kMANY_EVENTS);
        request.addQueryParameter("singleevents",
                                  aItemReturnOccurrences ? "true" : "false");
        request.addQueryParameter("start-min", rfcRangeStart);
        request.addQueryParameter("start-max", rfcRangeEnd);

        this.asyncItemRequest(request);
    },

If you try the request URL in a browser you will see (if you have a non USA as your google calendar default) not all data is returned. In the case of Sydney Australia which is +10hr.. You miss 10hr of data. if you format the request with the trailing T+.. all data is returned.

You can test this by viewing your calendar then trying a url like below (remember to change the [e-mail] to your calendar).

http://www.google.com/calendar/feeds/[e-mail]/private/full?start-min=2007-09-25&start-max=2007-09-26

This will return a USA based reply, if you reformat the start-min/max to include the Thh:mm:ss...etc.. It will return the correct data.

Hope this is explained ok..??

Comment 3

[Philipp Kewisch [:Fallen][📱📆]]

Yes, I understand now. This is either a flaw of rfc3339, a bug in the google server, or such. I do see the possible workaround, but you have to be careful. If you create an allday event, you must use only a DATE, not a DATETIME. If you change the code as above, then you will break allday events. Adding a paramter to toRFC3339() to either return DATEs or DATETIMEs might be a good idea. I'll think about the possibilities and come back to you. If you'd like to create a patch yourself, search developer.mozilla.org for "Creating a patch".

This will definitly make the next release.

Comment 5

[Philipp Kewisch [:Fallen][📱📆]]

Attachment: Fix v1

This basically does the same thing, but at a different location. I think the rfc3339 conversion functions should stay intact and the request date should be modified.

I'm taking this for the next release version.

Comment 6

[Daniel Boelzle [:dbo]]

Comment on attachment 285656 [details] [diff] [review]
Fix v1

>+        // Requesting only a DATE returns items based on UTC. Therefore, we make
>+        // sure both start and end dates include a time and timezone. This may
>+        // not quite be what was requested, but I'd say its a shortcoming of
>+        // rfc3339.

W.r.t. floating ranges: Wouldn't it be better if you tweak rangeStart to e.g. +14:00 and rangeEnd to e.g. -11:00 to cover all items?

BTW: I'd like to throw NS_ERROR_NOT_AVAILABLE on calIDatetime::timezoneOffset in case of floating times in the future. It currently returns just 0 which is IMO error prone.

Comment 7

[Philipp Kewisch [:Fallen][📱📆]]

If I tweak the ranges like that, I will be returning events far outside of the requested time range, which may cause Problems in other places, or do you mean to only do that for floating times? In what cases is calICalendar::getItems() called with floating times?

Do +14:00 and -11:00 have any special meaning? Are those the maximum timezone offsets?

The rfc tells me to specify -00:00 as the timezone offset, if its an "unknown local offset", which I'd say is a floating time, but I don't think Google does this correctly.

Comment 8

[Daniel Boelzle [:dbo]]

(In reply to comment #7)
> If I tweak the ranges like that, I will be returning events far outside of the
> requested time range, which may cause Problems in other places, or do you mean
> to only do that for floating times? In what cases is calICalendar::getItems()
> called with floating times?
Yes, that's what I meant. I can't remember code calling getItems with floating ranges.

> Do +14:00 and -11:00 have any special meaning? Are those the maximum timezone
> offsets?
I just picked some from tzdata.c.

> The rfc tells me to specify -00:00 as the timezone offset, if its an "unknown
> local offset", which I'd say is a floating time, but I don't think Google does
> this correctly.
So I think you could give it a try.

Comment 9

[Philipp Kewisch [:Fallen][📱📆]]

(In reply to comment #8)

> > The rfc tells me to specify -00:00 as the timezone offset, if its an "unknown
> > local offset", which I'd say is a floating time, but I don't think Google does
> > this correctly.
> So I think you could give it a try.
This is already being done, see calGoogleUtils' toRFC3339().

Comment 10

[Daniel Boelzle [:dbo]]

(In reply to comment #9)
> > So I think you could give it a try.
> This is already being done, see calGoogleUtils' toRFC3339().
Yes, but I meant you could give it try whether it works, some testing.

Comment 11

[Daniel Boelzle [:dbo]]

Comment on attachment 285656 [details] [diff] [review]
Fix v1

anyway, this would just be an enhancement; r=dbo

Comment 12

[Philipp Kewisch [:Fallen][📱📆]]

Checked in on HEAD and MOZILLA_1_8_BRANCH

-> FIXED

(This doesn't need to be checked in on sunbird 0.7 branch, since it is not being built by default anyway)

Target version is gdata 0.3, there will be no 0.2.2.

Comment 13

[Daniel Boelzle [:dbo]]

Rethinking my proposal from comment #6: This may of course return items that don't belong to the floating range; those need to be filtered which I think we don't want to, e.g. for performance reasons. Unless someone comes up with a good use case, I think we should tighten the API specifying that floating ranges are not allowed at all.

Comment 14

[Daniel Boelzle [:dbo]]

File follow up bug 400995 for comment #6.