Date related bug in stacked AreaChart when using Firefox and IE

[Carl Erik Kopseng]

The first post never showed up, so will try again ... 

I created a fiddle that shows a problem that only concerns IE and Firefox. Check it out here. You can see the resulting chart from the attached images. As you can see, one version is totally wrecked, whereas the other (Chrome) is fine. Both versions are fine if the dates are within the same year, but as soon as they cross Jan 1, the bug hits IE and Firefox ... Data for both the working version and the buggy version can be found in the fiddle.

[trybka]

You're quite right, it is the date parsing.

Your 2013 dates lack a leading zero on the month ('1' vs '01'). 

If you fix that, it will be parsed consistently with your other dates.

FWIW, it seems Chrome is more lax... but there's some more inconsistency, too. -- Try this in Chrome's console:

• new Date('2013-1-01')
  
• new Date('2013-01-01')
  

From http://stackoverflow.com/questions/5802461/javascript-which-browsers-support-parsing-of-iso-8601-date-string-with-date-par

 

Yes, Date.parse is not consistent for different browsers. You could:

• Use Date.UTC instead, which breaks up the date-string into separate inputs
• Use a wrapper library like jQuery's parseDate

-Tom

[Carl Erik Kopseng]

On Thursday, 27 September 2012 21:01:24 UTC+2, trybka wrote:

You're quite right, it is the date parsing.

Your 2013 dates lack a leading zero on the month ('1' vs '01'). 

If you fix that, it will be parsed consistently with your other dates.

If I could kiss you now, I would! Thank you! And sorry for reporting this as a bug. I actually did try creating Date objects using Internet Explorer in Firebug Lite, since I thought that might be the bug, but I guess I was lucky with which date strings I tested (or unlucky, depending on your view)...

Big love to the internets

-

Carl-Erik

[Daniel LaLiberte]

I would tend to consider it a bug because we are not being very robust about legitimate alternative date formats, though that is somewhat debatable.  

There is also another bug concerning the end date and time zone.  You'll note that in Firefox, the rightmost label on the horizontal-axis is missing (perhaps depending on where you are in the world), and this is because the January 1 date appears to be Dec 31 is some time zones.  So there is a confusion about the time zone of your data vs the time zone of the viewer.  

There are ways to work around these problems, but we have to decide how best to do that.

dan

--
You received this message because you are subscribed to the Google Groups "Google Visualization API" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-visualization-api/-/BSjS4bVWqUAJ.

To post to this group, send email to google-visua...@googlegroups.com.
To unsubscribe from this group, send email to google-visualizati...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-visualization-api?hl=en.

--

Daniel LaLiberte  - 978-394-1058

dlaliberte@Google.com   562D 5CC, Cambridge MA

daniel.laliberte@GMail.com 9 Juniper Ridge Road, Acton MA

[asgallant]

The dates are being input via a Date object, so this issue isn't one with the API.  The timezone issue is a side effect of the string-to-date conversion in Date objects.  For some reason, the Date object assumes strings of the format 'yyyy-mm-dd' are in UTC format and not the local time zone.

I would recommend that you parse the date strings and build the date objects in the standard format to fix that:

for (var i = 0, plen = expectedValuePoints.length; plen > i; i++) {
    var expected = Math.floor(expectedValuePoints[i].y);
    var lower = Math.floor(lowerLimitPoints[i].y);
    var upper = Math.floor(upperLimitPoints[i].y);
    var dateArr = expectedValuePoints[i].x.split('-');
    data.addRow([
        new Date(parseInt(dateArr[0]), parseInt(dateArr[1]) - 1, parseInt(dateArr[2])),
        lower,
        expected - lower,
        upper - expected
    ]);

}

On Thursday, September 27, 2012 6:01:50 PM UTC-4, Daniel LaLiberte wrote:

I would tend to consider it a bug because we are not being very robust about legitimate alternative date formats, though that is somewhat debatable.  

There is also another bug concerning the end date and time zone.  You'll note that in Firefox, the rightmost label on the horizontal-axis is missing (perhaps depending on where you are in the world), and this is because the January 1 date appears to be Dec 31 is some time zones.  So there is a confusion about the time zone of your data vs the time zone of the viewer.  

There are ways to work around these problems, but we have to decide how best to do that.

dan

On Thu, Sep 27, 2012 at 5:11 PM, Carl Erik Kopseng <carl...@gmail.com> wrote:

On Thursday, 27 September 2012 21:01:24 UTC+2, trybka wrote:

You're quite right, it is the date parsing.

Your 2013 dates lack a leading zero on the month ('1' vs '01'). 

If you fix that, it will be parsed consistently with your other dates.

If I could kiss you now, I would! Thank you! And sorry for reporting this as a bug. I actually did try creating Date objects using Internet Explorer in Firebug Lite, since I thought that might be the bug, but I guess I was lucky with which date strings I tested (or unlucky, depending on your view)...

Big love to the internets

-

Carl-Erik

--
You received this message because you are subscribed to the Google Groups "Google Visualization API" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-visualization-api/-/BSjS4bVWqUAJ.

To post to this group, send email to google-visua...@googlegroups.com.

To unsubscribe from this group, send email to google-visualization-api+unsub...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/google-visualization-api?hl=en.

--

Daniel LaLiberte  - 978-394-1058

dlali...@Google.com   562D 5CC, Cambridge MA

daniel.l...@GMail.com 9 Juniper Ridge Road, Acton MA