First of all, assuming the computer running your strategy
has an accurate local clock synchroniz(s)ation...

then wouldn't it generally be true that

boolean isLater = (  System.currentTimeMillis() >= tick.getTime() ); // always true ?

I realize that System.currentTimeMillis() may be accurate only to 10 msecs,
but let's assume it gives an accuracy to 1 msec.

HyperScalper

OK, still waiting for an answer so, in the meantime, here's another related question:

In the Strategy onTick(...) callback, we can obtain the ITick's timestamp using

// get this tick's timestamp
long timestamp = tick.getTime(); // inherited from ITimedData

Whether this tick.getTime() is done in New York, Geneva or Melbourne,
isn't it the SAME actual value for a given tick?

It is independent of Time Zone, and of local System clock, right ?

My understanding is that the Java time represents a universal "instant" in time.

HyperScalper

tick.getTime(), bar.getTime() are timestamps in GMT, so they are not independent from timezones...
And probably the time when they hit dukascopy's server.

boolean isLater = (  System.currentTimeMillis() >= tick.getTime() ); // always true ?

ANSWER TO THE QUESTION:
Given your stipulations, yes this is generally always true if we also presume three things:

• Very accurate local clock synchronis(z)ation (a stable and adaptive distributed algorithm taking into consideration both clock resolutions, latency over the communications channel, etc.)
• Local clock shares the exact same timebase (normally UTC/GMT 00:00:00 January 1 1970) and time progression scheme (e.g flipping in and out of DST at the same time if applicable - most systems dont do this at the timestamp/system clock level) as the tick server
• Nothing is happening on the local system at the hardware or system software level to hit the internal time keeping elements before and/or after synchronisation

Regarding point 2, Dukascopy maintains a UTC base and GMT timestamp at all times and does not reflect any regional day-light saving time schemes in the stamps.

EXTRA INFO BEYOND THE ANSWER:
If at all possible, we stay away from having to interpret certainly tick (and perhaps sub-second timestamped) streams in terms of the local computer time.

Constant comparisons are fine e.g. long NOON = 425863726743; following by if (NOON >= tick.getTime()) i.e. "if the time the tick entered the server was at or before NOON"
(this is a local check but it is sound as it is considering the time on the server when the tick came in to the server)

Asking "if the time on my computer" is greater than or equal to "the time this tick entered the server" means there is trust that the time of the computer is sound with respect to the time on the tick source.

Regarding point 1, 99.9% of the time "logical synchronis(z)ation" works out.

To see where the remaining 0.1% goes let's consider communication with Dukascopy not by copper wire but by some futuristic special wavelength of light with approx 0.0ns latency. If the tick enters Dukascopy servers via instant-light-beam and is propagated to a local API instance instantly, the synchronisation algorithm trying to match the server's clock won't be perfect and in many cases will both over and under compensate meaning the local clock time might fall ever so slightly behind the server (at milli- or nano- resolution) and the >= check falls apart. So even where tick reception is instant, when the basis of keeping time relies on some distributed algorithm in the background that is working to keep the local CPU clock in sync with a remote clock over a comms channel with zero latency guarantees we have potential issues.

For a 100% case synchronisation would have to be via the same shared and physical clock source and latency would have to be guaranteed and uniform over the channel allowing the local clock element to reference the shared physical source.

// get this tick's timestamp
long timestamp = tick.getTime(); // inherited from ITimedData

Thankfully we can forget all about Java when it comes to ALL TIMESTAMPS provided within the JForex API.

If you apply the JForex API in all of Los Angeles, Paris, Moscow and Sydney, the API promises to deliver to you the next tick as soon as it arrives at the tick server. The current time where you are when this happens of course makes no difference to this promise.

The API promises that when you receive the tick, it will be timestamped in GMT time which is the reference time maintained by the tick server.

All the timestamps emanating from the tick server will be stamped in server time and it won't matter where you are physically or timezone wise when you receive this information from the server over the API. This is a core guarantee and promise of the API.

The real fun and games begin when we start parsing the raw timestamps through Java convenience objects instantiated within JVMs running under various LOCALE/TIMEZONE settings

Interesting follow up, CriticalSection. As always...

Could you explain why? If the tick's timestamp is the GMT time of the server when the tick arrived, no matter what I do with this time data (put it in a different timezone), it will be always an accurate reference, isn't it?
I assume that time zone modification is just adding/subtracting couple of hours, not touching the minute, second, millisecond part of a time value. Or do I underestimate this?

Yes, most definitely. The 'long' variable will always retain its value as communicated by the server.

Indeed this is right. The long value is never manipulated directly. Manipulations happen within convenience objects such as Calendar and SimpleDateFormat, etc used to convert the 'long' timestamp into human readable time.

So for example when I started with JForex working in the winter, all the times in my logs corresponded with GMT but as soon as summer time came around everything was off by 1 hour (BST British Summer Time ) leading me to believe a bug existed.

Outputting the timezone along with the time in my logs revealed the GMT vs BST difference as a consequence of using convenience objects but forgetting to set them to interpret the timestamp not in local time (which of course can be anything) but in GMT time.

p.s. Thanks a lot for the blog like, I really appreciate it - reputation is like air in the Community section :p

Yes, they are independent of Time Zone, I am quite sure.
They are timestamped when the Price Tick originates at Dukascopy,
and that timestamp should never change.

The Date() constructor accepts one argument that equals the number of milliseconds that have elapsed since midnight, January 1, 1970 GMT represented in a long variable.

The number of milliseconds, so it is independent of how that is represented in a Time Zone,
I believe.


HyperScalper