milisecond precission in timeseries

[GoogleCodeExporter]

I see a timeseries is expecting double and I couldn't find a way to add time to 
the precission of miliseconds to timeseries.From miliseconds point of view a 
long type would be preferable than double.

I see that Long 1341138961423 is convert to Double 1341138861000.00 within 
gflot library.

Is it this possible to add this functionality or is there a way to use it with 
current version of gflot library somehow?

Original issue reported on code.google.com by klemenzi...@gmail.com on 1 Jul 2012 at 10:37

[GoogleCodeExporter]

Also sometimes happens that lines in chart are created in past (see picture 
where two such lines were created?).

plotoptions used:

        plotOptions.setGlobalSeriesOptions(new GlobalSeriesOptions().setLineSeriesOptions(new LineSeriesOptions().setLineWidth(1).setShow(true))
                .setPointsOptions(new PointsSeriesOptions().setRadius(2).setShow(true)).setShadowSize(0d));
        plotOptions.addXAxisOptions(new TimeSeriesAxisOptions());
        plotOptions.setCrosshairOptions(new CrosshairOptions().setMode(Mode.XY));
        plotOptions.setGridOptions(new GridOptions().setHoverable(true).setAutoHighlight(false));

Has anybody else experienced such behaviour ?

Original comment by klemenzi...@gmail.com on 1 Jul 2012 at 10:56

Attachments:

• gflot.png

[GoogleCodeExporter]

Could you provide an example ? I didn't reproduce the problem. 

And there will never have a support for long. From the GWT documentation :

long: JavaScript has no 64-bit integral type, so long needs special 
consideration. Prior to GWT 1.5, the long type was was simply mapped to the 
integral range of a 64-bit JavaScript floating-point value, giving long 
variables an actual range less than the full 64 bits. As of GWT 1.5, long 
primitives are emulated as a pair of 32-bit integers, and work reliably over 
the entire 64-bit range. Overflow is emulated to match the expected behavior. 
There are a couple of caveats. Heavy use of long operations will have a 
performance impact due to the underlying emulation. Additionally, long 
primitives cannot be used in JSNI code because they are not a native JavaScript 
numeric type.

Original comment by nmr.morel on 5 Jul 2012 at 9:13

[GoogleCodeExporter]

Ok, my appologies - It was my bug on server side. Everything works as expected 
- great library - keep up good work!!

Please close issue...

Original comment by klemenzi...@gmail.com on 6 Jul 2012 at 7:40

[GoogleCodeExporter]

Original comment by nmr.morel on 6 Jul 2012 at 11:17

• Changed state: Invalid