Calendar start and end date are not correctly generated

[vladlep]

The start_date is always set to the last day of the previous month while the end date is set to one day earlier than the it should be. In this way i miss getting the data fro the 28th of feb and 31st of march in my example "https://my_example/get/calendar/92/?start_date=2014-01-31T23:00:00.000Z&end_date=2014-02-27T23:00:00.000Z&user_id=4"."

https://my_example/get/calendar/data/?start_date=2014-02-28T23:00:00.000Z&end_date=2014-03-30T22:00:00.000Z&user_id=4".".

I used the latest unminified heatmap with this initialization:

function getUpdateUrl(){
    return url_get_calendar_data +"?start_date={{d:start}}&end_date={{d:end}}"+"&user_id="+getUserId();
}

    cal.init({
        itemSelector: "#example-g",
        data: getUpdateUrl(),
        start: selected_date,
        cellSize: 25,
        itemName: ["hour", "hours"],
        cellPadding: 4,
        domain: "month",
        subDomain: "x_day",
        range: 1,
        legend: [1, 2, 4 ,8 ],
        displayLegend: false,
        nextSelector: "#nextMonthSelector",
        previousSelector: "#prevMonthSelector",
        highlight: ["now", selected_date],
        subDomainTextFormat: "%d",
        subDomainTitleFormat : {
            empty: "No data on {date}",
            filled: "{count} {name} {connector} {date}"
        },
        domainLabelFormat: "%B %Y",
        onClick: function(date,value) {
            $.event.trigger(
                {
                    type: "changeDate",
                    newDate: new Date(date)
                })
        },
        afterLoadData: pre_format_data
    });

If there is more information needed or if you think i did something wrong, please let me know. Thanks

[vladlep]

For me i solved this issue by changing the in the parseURI function from the ISO format to dd-MM-yyyy:

str = str.replace(/\{\{d:start\}\}/g, startDate.toString("dd-MM-yyyy"));
str = str.replace(/\{\{d:end\}\}/g, endDate.toString("dd-MM-yyyy"));

Otherwise based on my timezone I would get strange starting intervals as explained above.

[wa0x6e]

Are you in a timezone with daylight saving ?

[vladlep]

I am in Europe/Amsterdam +01 and yes, it is a timezone with daylight savings

[wa0x6e]

I think that Date.toString() does not take any arguments. The change you made is using toString() instead of toISOString().

What's the url looks like after your edit ?

[vladlep]

Sorry again, but as i said on the other bug, i migrated the calendar to use a jquery one instead of d3. From what i remember:

• we used date.js library which offers the possibility to format the data as you wish, see link below https://code.google.com/p/datejs/wiki/APIDocumentation
• the urls turned out: https://my_example/get/calendar/92/?start_date=2014-02-01&end_date=2014-02-28&user_id=4

[infacq]

I am in Asia/Kuala_Lumpur. Still face the same problem

[fabio-a-beretta]

I have the same issue. After a brief check it appears that the end date is using the same date at midnight 00:00:00. This excludes 1 day from the domain. If the end date is converted to 23:59:50 or better at Day+1 at 00:00 it seems to work.

I have corrected the function as follows: adding endDate.setDate(endDate.getDate() + 1).

parseURI: function(str, startDate, endDate) {
		"use strict";

		// Added to correct bug in date selection
		endDate.setDate(endDate.getDate() + 1)

		// Use a timestamp in seconds
		str = str.replace(/\{\{t:start\}\}/g, startDate.getTime()/1000);
		str = str.replace(/\{\{t:end\}\}/g, endDate.getTime()/1000);

		// Use a string date, following the ISO-8601
		str = str.replace(/\{\{d:start\}\}/g, startDate.toISOString());
		str = str.replace(/\{\{d:end\}\}/g, endDate.toISOString());

		return str;
	},

May be can be check it and introduce it into the code.

Thanks, Fabio

[wa0x6e]

.toISOString() should always return an UTC time, so not timezone dependent. If your backend is not returning the correct dates, it may be because it does not parse the date with the correct timezone.

the endDate is indeed the last subdomain of the calendar, so it it's a yearly calendar by days, endDate is 31 December, at 00:00, and you indeed lose data for the last day.

v4 will fix this issue