[ts-gen] seconds clamps to zero after midnight

Bill Pippin pippin at owlriver.net
Tue Sep 1 16:34:56 EDT 2009


Ken,

Thanks much for your bug report.  With, by way of example, a market
data price event:

> 2448|05751|  0.196496|3| 1| 5|7|1|...|...|1|price. ...|CASH::EUR:JPY:

> ... everything is fine until midnight, local-time.  [Then the
> time-stamp, here 05751] ... clamps down to 00000 and stays there ...

This is a bug in releases of the shim up through 090826, that is
all those previously available, and is now fixed in the 090901
tarball, the one I just pushed in response to your report.

In wait.c, for the check_tick() procedure that catches clock ticks,
although there was a check for midnight rollover, and the time since
midnight variable was (correctly) reset to zero, the cached value
for the midnight time itself was not updated.  In the newly released
code, this is fixed.

> ... the first 6 numbers come in unfiltered from the upstream TWS,
> right?  So this is a TWS problem, I assume?

No, the problem was in the shim.  As for the event log format, there
is a prefix provided by the shim; the IB tws api log text itself, with
little if any filtering other than whitespace formatting; and then
an optional suffix.  For the log event text example you've provided,
I've split the event below onto three lines:

    prefix: 2448|05751|  0.196496|3|
   message: 1| 5|    7| 1|  132.46500| 2250000|1|
    suffix: price.outcry.bid.   |CASH::EUR:JPY:

In the event text above, the prefix gives: the shim process id;
seconds since midnight; fractional time value, here microseconds
since last event; and the event class, typically one of 1, 2, 3,
or 4, as the event is a command, request, message, or comment.  To
translate the message itself, you should see the file EReader.java
from the sample client sources.  The suffix, if any, is typically
just the contract symbol expression, and so here the price/size
message subtype expansion for market data is an exception to that
general rule.

> It's not hard to fix the problem - if I bring TWS and shim down,
> and then bring them back up again, the number is right again.

True.

> ... Is bringing TWS and shim down and back up, straddling
> midnight, the only solution to this problem?

Given the bug, it was before, although that was not our intention;
and now, with the fix, you'll see time wrap around as you would
expect.  E.g., for a shim session with pid 25948, and on a machine
maladjusted to believe it to be nearly midnight:

    25948|86400|  0.000007|3| 1| 5|    7| 2| ...
    25948|86400|  0.000005|3| 2| 5|    7| 0| ...
    25948|86400|  0.000003|3| 2| 5|    7| 3| ...
    25948|86400|  0.249689|3| 2| 5|    7| 5| ...
    25948|86400|  0.000202|3| 2| 5|    7| 8| ...
    25948|00001|  0.000000|3| 2| 5|    7| 8| ...
    25948|00001|  0.000377|3| 2| 5|    7| 0| ...
    25948|00001|  0.000005|3| 2| 5|    7| 3| ...
    25948|00001|  0.499751|3| 2| 5|    7| 0| ...
    25948|00001|  0.000006|3| 2| 5|    7| 3| ...
    25948|00002|  0.501029|3| 2| 5|    7| 8| ...

Thanks,

Bill



More information about the ts-general mailing list