GMT to Server - page 2

3944

nicholishen: I still don't see where you're going there by adding thirty minutes to the delta then dividing by 60 min... ???

Why not just keep it simple and let int division do its thing? There's no need to over-complicate it.

Because standard integer division results in the equivalent of the "floor()" function being applied.

So, in order to get the equivalent of "round()", you add half the value of the divisor, just as @whroeder1 explained.

It is not "over-complicating" things, but in fact the correct way to handle it.

1538

Fernando Carreiro:

Because standard integer division results in the equivalent of the "floor()" function being applied.

So, in order to get the equivalent of "round()", you add half the value of the divisor, just as @whroeder1 explained.

It is not "over-complicating" things, but in fact the correct way to handle it.

Under what circumstances would this ever be true?

`((TimeCurrent()-TimeGMT())%3600 != 0)`

Edit: other than a closed market

3944

nicholishen: Under what circumstances would this ever be true?

Edit: other than a closed market

Sorry, but I am not exactly following your reasoning. What exactly is your point with the "modulus" (correction "modulo")?
1538

Fernando Carreiro:
Sorry, but what exactly is your point with the "modulus"?

Under what circumstances would the modulo return anything other than 0? What am I missing? Server-time always runs the increment of hours ahead or behind GMT, not minutes. Therefore...

```((TimeCurrent()-TimeGMT())%3600 == 0)
```

Should always return true... unless they used different clocks. Is that what I'm missing do they somehow use different clocks?

3944

nicholishen:

Under what circumstances would the modulo return anything other than 0? What am I missing? Server-time always runs the increment of hours ahead or behind GMT, not minutes. Therefore...

Should always return true... unless they used different clocks. Is that what I'm missing do they somehow use different clocks?

As @whroeder1 explained, "there will be jitter on reading both timestamps". That slight delay can cause the two readings to be off on the very transition between for example 23h59 to 00h00.

Lets say that you were able to read both functions simultaneously without any jitter, so that one would read 23h59 and other would read 22h59 (1 hour difference between the two).

However due to a slight delay (called "jitter" in several fields) between reading the two functions, what you actually get is 23h59 and 23h00 due the time changing during that slight delay.

How would YOU handle that jitter?

PS! The clocks being slightly out of sync can be resolved this way as well.

EDIT: Please note that jitter is caused mainly by the network delays but can also be caused by the execution delays (or even other reasons).

Moderator
35055

nicholishen:

Under what circumstances would the modulo return anything other than 0? What am I missing? Server-time always runs the increment of hours ahead or behind GMT, not minutes. Therefore...

Should always return true... unless they used different clocks. Is that what I'm missing do they somehow use different clocks?

Actually I would say : almost always.

`((TimeCurrent()-TimeGMT())%3600 == 0)`

TimeCurrent is broker server time.

TimeGMT is based on local computer time.

It's very unlikely they will always be exactly synchronized. Anyway while coding you need to take into account the worst case scenario.

Moderator
35055

Fernando Carreiro:

As @whroeder1 explained, "there will be jitter on reading both timestamps". That slight delay can cause the two readings to be off on the very transition between for example 23h59 to 00h00.

Lets say that you were able to read both functions simultaneously without any jitter, so that one would read 23h59 and other would read 22h59 (1 hour difference between the two).

However due to a slight delay (called "jitter" in several fields) between reading the two functions, what you actually get is 23h59 and 23h00 due the time changing during that slight delay.

How would YOU handle that jitter?

PS! The clocks being slightly out of sync can be resolved this way as well.

The main reason is the "out of sync" one. Highly probable.

This "jitter" is completely negligible, we are working with datetime, precision to second, calling a function like TimeGMT() is a matter of microseconds. 1 chance on 1,000,000 to have a time shift using "second" precision. (Ok maybe 2 or 3 chances, I didn't measure).

3944

Alain Verleyen:

The main reason is the "out of sync" one. Highly probable.

This "jitter" is completely negligible, we are working with datetime, precision to second, calling a function like TimeGMT() is a matter of microseconds. 1 chance on 1,000,000 to have a time shift using "second" precision. (Ok maybe 2 or 3 chances, I didn't measure).

I disagree. Network jitter, especially in high latency connections, is the main problem!

The Server time update can even be delayed several minutes behind (not just seconds) when network problems are more severe!

Worse even, especially when no ticks are arriving, the server time does not even update at all sometimes (I have seen that happen many times).

EDIT: Just watch the "Market Watch" panel closely for a minute and see how irregularly it keeps time!

EDIT2: Anyway, that is not really the issue here. The rounding being applied in the calculations was in fact the main point in this discussion!

Moderator
35055

Fernando Carreiro:

I disagree. Network jitter, especially in high latency connections, is the main problem!

The Server time update can even be delayed several minutes behind (not just seconds) when network problems are more severe!

Worse even, especially when no ticks are arriving, the server time does not even update at all sometimes (I have seen that happen many times).

EDIT: Just watch the "Market Watch" panel closely for a minute and see how irregularly it keeps time!

That's an other point entirely.

Calling TimeCurrent() doesn't implied any network or "high latency". It's executed locally not on the server.

Of course your last point is valid (no ticks, or delay,etc). That's why TimeCurrent() should not be used at all for such usage. But we are far from the OP question.

3944

Alain Verleyen:

That's an other point entirely.

Calling TimeCurrent() doesn't implied any network or "high latency". It's executed locally not on the server.

Of course your last point is valid (no ticks, or delay,etc). That's why TimeCurrent() should not be used at all for such usage. But we are far from the OP question.