|
 reverse call from xxx.charttime() |
| Posted by DC Kelley on Sep-10-2013 22:40 |
|
From the API documents:
> ChartDirector provides a function Chart::chartTime that returns a ChartDirector date/time...
Is there a call or method that will allow displaying the values (year/month/day.../sec) of such a double. I am seeking a way to assist in debugging the values I have set. It seem like the only to calls are "one way" in this regard.
My core need is to plot and coordinate several different GNSS time systems [such as the US GPS which uses weeks (int), and time of week(double)] into and out of the CD time scale. Precise scaling (values with high precision in the fraction of a second) are handled another way, this need deal with crossing over multiple day/week/leap second periods.
Extra credit: Is there a table anywhere documenting the time in CD seconds when various time systems were resent or set to zero with respect to the CD system of zero at the the start of the BCE point? |
| Re: reverse call from xxx.charttime() |
| Posted by Peter Kwan on Sep-11-2013 00:21 |
|
Hi DC Kelley,
There are several methods:
(i) The Chart::getChartYMD method will return the yyyymmdd as an 8 digit integer. So you can get the year, month and day of month parts. The ss, nn and hh can be obtained using simply division:
int secondsOfDay = (int)fmod(myChartTime, 86400);
int ss = secondsOfDay % 60; // the remainder when divided by 60
int nn = (secondsOfDay/60) % 60;
int hh = secondsOfDay/3600;
(ii) You may use BaseChart.formatValue. For example:
const char *yyyymmddhhnnss = myChartObject->formatValue(myChartTime, "{value|yyyymmddhhnnss}");
Unluckily, there is no table for the time in CD seconds when various time systems were resent or set to zero with respect to the CD system of zero at the the start of the BCE point.
Regards
Peter Kwan |
| Re: reverse call from xxx.charttime() |
| Posted by DC Kelley on Sep-11-2013 03:02 |
|
Looks like the Chart::getChartYMD method can let me confirm the values are close, but that last second is the killer here.
> int secondsOfDay = (int)fmod(myChartTime, 86400);
Peter, I do not think that would reliably work.
Would it not creep with every new leap second? It seems to me that those rare days (those 16 days in the last 30 odd years with leap seconds) will cause a cumulative error that must be addressed. [For those that do not know, UTC has occasional and unpredictable leap seconds added when needed, while GPS does not, hence they diverge over time]
I am trying to plot some GPS events on a UTC time scale (as Chart Director thinks in) both before and after June of 2012 when the last change in the count of leap seconds occurred. I have figured out how to display the current TOD (time of day) in the axis label with a line like:
c->xAxis()->setLabelFormat("{={value|0}%86400}\\n{value|nn:ss}")
If I used a label line like this it seems I may be a) forced to display in UTC time (not GPS time) and b) the displayed time will walk by one second every time there is new leap second. To restate, I wish to display in GPS 'time of day' seconds (which are currently 16 seconds ahead of UTC) and to be able to span displays when the TOD value rolls over (this happen at 5PM here in California). So in such a case the data for CD to plot will simply advance using your UTC time system, but the label displayed will reset to zero.
The ideal approach to this eludes me. Any advice? |
| Re: reverse call from xxx.charttime() |
| Posted by Peter Kwan on Sep-12-2013 01:43 |
|
Hi DC Kelley,
The "int secondsOfDay = (int)fmod(myChartTime, 86400);" will work because it is the definition of the date/time used in ChartDirector. The chartTime is essentially an encoding of a date/time as your read on calendars and clocks, and the hh, nn, ss are encoded based on the above method. This type of date/time system is commonly used in database.
Another common date/time system used in computers is physical elapsed time (typically expressed in seconds since some instance in time).
Unluckily, it is not practical to convert a physical time into human readable format accurately. To do that, apart from the leap second, one must know the daylight saving time (DST) rule. (With DST rule, a day can have 23 hours or 25 hours, in addition to the possibility of a leap second.) Unluckily, DST is different among countries and can change arbitrarily, and sometimes the DST rule is not officially documented, so historical DST rules for all countries are hard to keep track of, and it is not possible to predict future DST rules (but it is commonly for charting to plot future time).
Most programming languages have functions to convert physical elapsed seconds into human readable format. They simply assume that the current DST rule applies also to historical and future times, so the resulting human readable date/time obtained may be inaccurate.
For your case, if you have a GPS time, and you know what it should be displayed in yyyy mm dd hh nn ss (be it using UTC, UTC+16, or any other rule), you can just encode the yyyy mm dd hh nn ss into an integer using chartTime. The exact rule you use to come up with the yyyy mm dd hh nn ss is not important to ChartDirector. Basically, ChartDirector would just display what you provides. It does not need to know the physical meaning of any values.
Hope this can help.
Regards
Peter Kwan |
|
Forum Home
Search
Message List
Post Message