Quinn-Curtis Forums
Quinn-Curtis Forums
Home | Profile | Register | Active Topics | Members | Search | FAQ
Username:
Password:
Save Password
Forgot your Password?

 All Forums
 Tools for Java
 QCChart2D for Java
 Daylight savings problem
 New Topic  Reply to Topic
 Printer Friendly
Author Previous Topic Topic Next Topic  

KnightHawk

22 Posts

Posted - 13 Nov 2007 :  15:59:13  Show Profile  Reply with Quote
I am not quite sure where to put this problem. I am charting data in real time, but I'm not sure what seems to be at fault.

My problem is that when I am feeding an RTProcessVar with data that spans a daylight savings time change (only found so far with MDT to MST), the processor runs at maximum and the chart window locks up. (All times are mountain standard / daylight time).

The problem first showed up on:
Sunday November 4th at 1:00:10 am MST,
The previous date that the program charted was:
Sunday November 4th at 12:59:40 am MDT

Going across a daylight savings time seems to loop something or hang on something, although no exceptions were ever thrown.

When I turn off "Automatically adjust clock for daylight savings" in the windows time settings, the program does not crash. This seems to be because the gregorian calendar will use the GMT time zone with a -7 hr offset.

With "Automatically adjust clock for daylight savings" on, the gregorian calendar shows time zones MDT before sunday november 4th at 1:00 am, and MST after 1:00 am, and the error occurs.


Printing out the gregorianCalendar.getTime() and gregorianCalendar.getTimeInMillis() provides:
Sun Nov 04 00:59:49 MDT 2007 1194159589000
Sun Nov 04 01:00:19 MST 2007 1194163219000

Although the time doesn't seem to change, the time in milliseconds is up an hour.

How does the charting software deal with daylight savings time and what could be the problem on my end?

quinncurtis

1164 Posts

Posted - 13 Nov 2007 :  17:01:40  Show Profile  Reply with Quote
That's an interesting problem and we are not sure we can give you a solution. The software does not process daylight savings time breaks.

The RTProcessVar methods assumes that the time data the you feed it is always monotonic, that is to say the time stamp is always increasing. If you are just feeding in the time that the system clock gives you, or are using our automatic time stamp that just uses the current system clock value, you will invalidate the monotonic requirement if you run it across a daylight savings time break where the time is set back. Setting the time forward should have no signficant affect, since the time stamps will still be monotonic; the graph would just appear to jump foward an hour.

Our only suggestion at this time is that you will have to stop and restart the graph when the clocks are set back, and not enter time data that jumps backward into the same RTProcessVar dataset.




Go to Top of Page

quinncurtis

1164 Posts

Posted - 13 Nov 2007 :  19:37:52  Show Profile  Reply with Quote
We modified the ScrollApplication1 example program to simulate setting the clock back while running and we could not reproduce the problem you describe. The traces of the scroll graph would go backward by an amount equal to the time shift and start plotting as before. You end with the time shifted area being plotted twice, with a retrace line.

When you say the chart locks up, are you sure that it is just not plotting the data back in time, off-screen, where you can't see it. The software plots the most recent data, according to the time stamp. So at 1:00 AM it will appear to stop because new data is being entered that is at 0:00, 0:01, etc. Until the time stamp is greater than 1:00 it will not start scrolling again.

What plot types are you using in your graph?

If you comment out the creation of the plot types, so that no plot lines actually appear in the graph, does the problem go away ?

Try and set the ScrollFrame ScrollMode property to RT_NOT_MONOTONIC_X_MODE.


scrollFrame.setTimeStampMode(ChartConstants.RT_NOT_MONOTONIC_X_MODE);


Go to Top of Page

KnightHawk

22 Posts

Posted - 14 Nov 2007 :  12:06:42  Show Profile  Reply with Quote
Thanks for your help. I will try the things you have suggested and see where I get. I will also inform you of anything I've found.
Go to Top of Page

KnightHawk

22 Posts

Posted - 20 Nov 2007 :  16:40:08  Show Profile  Reply with Quote
I implemented:
scrollFrame.setTimeStampMode(ChartConstants.RT_NOT_MONOTONIC_X_MODE);
but that did not help.

The type of chart I am running has a TimeAxis on the X-axis, and a linear Y-axis.

I set up the X-axis TimeAxis as:

TimeAxis axis = new TimeAxis(coordinates, startTime, endTime);
axis.setColor(color);
axis.setTimeAxisMin(startTime);
axis.setTimeAxisMax(endTime);

I found that when I do not add the TimeAxis to the Chartview, the data comes in fine, or I run a log x axis, it runs fine. So it appears either I am doing something wrong with setting up the time axis or something gets hung up with the TimeAxis when there is a disparency in times.

When I put duplicate datapoints into an RTProcessVar it does exactly what you described; the plot goes back and re-writes the data.

What happens when I go across daylight savings is the CPU hits max, and any updating of the program be it data retrival or Chartview.updateDraw() seems to halt.


Printing out the gregorianCalendar.getTime() and gregorianCalendar.getTimeInMillis() provides:
Sun Nov 04 00:59:49 MDT 2007 1194159589000
Sun Nov 04 01:00:19 MST 2007 1194163219000

The error I wanted to describe here is that although the time shows up (Sun Nov 04 00:59:49 MDT 2007) and (Sun Nov 04 01:00:19 MST 2007)
the only thing that changes is just MDT changes to MST, Where the time in milliseconds actually does jump an hour (the literal time).
This might be attacking Time Axis somehow.

I don't think that simulating the data as you described will properly highlight the error. If you could try to create time that would cross daylight savings time, it might help re-produce the error.

Let me know if you would like an example dataset to use.

Thanks.
Go to Top of Page

quinncurtis

1164 Posts

Posted - 20 Nov 2007 :  17:08:58  Show Profile  Reply with Quote
Sorry, we can't reproduce the problem using our own exmaple programs. So you will need to either modify one of our examples to reproduce the problem, and supply us with the modified file; or you need to supply us with the complete source to your own simple example program that reproduces the problem, along with a description of what steps to follow. Send the zipped folder of the source files, along with your description, to support@quinn-curtis.com.
Go to Top of Page

KnightHawk

22 Posts

Posted - 20 Nov 2007 :  17:14:57  Show Profile  Reply with Quote
Do you use Eclipse?
Go to Top of Page

quinncurtis

1164 Posts

Posted - 20 Nov 2007 :  17:29:49  Show Profile  Reply with Quote
Yes, we run Eclipse under Windows. It would be easiest if you made your example reside under our RT examples folder, com.quinncurtis.rtgraphjava.examples
Go to Top of Page
  Previous Topic Topic Next Topic  
 New Topic  Reply to Topic
 Printer Friendly
Jump To:
Quinn-Curtis Forums © 2000-07 Quinn-Curtis, Inc. Go To Top Of Page
Powered By: Snitz Forums 2000 Version 3.4.07