Bad dates on daily data

[Roland B]

Hi,

When I open an advanced chart versus a standard chart (whether graph or tabular), all daily data is back-dated by one day !?
The same holds for data exports.
e.g. QQQQ Close is 54.00 on standard chart and csv export file for 11/01/07, on advanced chart for 10/31/07.
On the advanced chart, the rightmost vertical dotted line suggests that the last bar occured on the first day of a new month. The detailed OHLC window gives the same wrong date. Some months on the horizontal axis are late by a full month and every other month label occurs double while every succeeding month does not show.
Jan and Feb are late by 1 month, Mar does not show. Apr is on time, but occurs twice. May is late by one month. un is missing. Jul is on time again, but occurs twice etc.
Since I only use these charts from time to time to verify other data streams, it is confusing, but not critical. On the other hand, I have not checked any other configurations for similar discrepancies.
As a matter of principle though, these kinds of inconsistencies can be very dangerous for automated trading, since who is to tell which data set is correct? Trading with data and indicators that are one bar off could be devastating.
This could of course be a visual glitch, and all data sent trough the feed could be 100% correct.
Please confirm. Thanks.

[ACM]

Roland B
Based on what I have seen the problems you are describing are caused by the Date/Time Settings (in Preferences) when this is set to Exchange Timezone or Greenwich Mean Time and the exchange or GMT is located in a different timezone than yours. Note that the data in itself is correct only the dates are misplaced.
If that is your case then the interim solution is to set the Date/Time Settings to Local Timezone which should resolve the problems you are seeing (see screenshots enclosed below).
It is my understanding that eSignal's developers have been informed of these issues which are slated to be fixed in a maintenance release due sometime in the near future.
Alex

Originally posted by Roland B
Hi,

When I open an advanced chart versus a standard chart (whether graph or tabular), all daily data is back-dated by one day !?
The same holds for data exports.
e.g. QQQQ Close is 54.00 on standard chart and csv export file for 11/01/07, on advanced chart for 10/31/07.
On the advanced chart, the rightmost vertical dotted line suggests that the last bar occured on the first day of a new month. The detailed OHLC window gives the same wrong date. Some months on the horizontal axis are late by a full month and every other month label occurs double while every succeeding month does not show.
Jan and Feb are late by 1 month, Mar does not show. Apr is on time, but occurs twice. May is late by one month. un is missing. Jul is on time again, but occurs twice etc.
Since I only use these charts from time to time to verify other data streams, it is confusing, but not critical. On the other hand, I have not checked any other configurations for similar discrepancies.
As a matter of principle though, these kinds of inconsistencies can be very dangerous for automated trading, since who is to tell which data set is correct? Trading with data and indicators that are one bar off could be devastating.
This could of course be a visual glitch, and all data sent trough the feed could be 100% correct.
Please confirm. Thanks.

[Roland B]

Hi,

Thanks for your prompt help in this matter. I really do appreciate.
Your trick does help - visually - to some extent. Programmatically, I continue to have serious trouble. If you try to write an application that should be able to cope with different datafeeds, it is rather cumbersome to deal with idiosyncracies such as the ones offered by eSignal. It so happens that I live 6 timezones away from the East coast. Between the eSignal application, my development environment, my various backup and other utilities, I spend a considerable amount of nerves setting dates/times, because I need a particular date/time to view data in eSignal, another to download or process it programmatically, another to do backups in order to be consistent with daily, monthly, yearly backup schemes and so on, simply because after years of development, eSignal developers have not managed to get a grip on one of the most basic features.
For instance, I have to switch date/time between realtime and history data, otherwise the number of days for which I request history data is incorrect. Date/time for realtime data is easy to convert. Never mind that all of this behavior changes for a few hours sometime after midnight EST (early morning in Europe) whith every new day.
This whole problem is shifted by one hour up/down twice a year with summer/winter times.
I've been subscribing (and incidentally paying) for close to 4 years now, without ever getting any joy out of this feed anytime that I attempted to wrestle with it.
At the latest after acquiring Quote.com, eSignal developers must have gotten a look at how simple a datafeed can be. For instance, Quote.com used to send a timestamp with every single record. This uses bandwidth but resolves any doubt about the correctness/latency of the data one is receiving. Compare this to the ridiculous addition of a timestamp within winsig - i.e. after reception of data.
The latest in this glory:
I am currently looking at QQQQ 1-minute data.
02 Nov seems OK
01 Nov seems OK
31 Oct seems OK
30 Oct seems OK
29 Oct: no data between 14.29 and 18.44 (i.e. after subtracting 5 hours: between 09.30 and 13.44)
now we change to winter time
26 Oct: no data between 15.29 and 21.52 (i.e. after subtracting SIX hours: between 09.30 and 15.52)
I'll spare you previous days.
We are not getting 120 days of stored 1-minute data - we are getting FOUR days - and who is to trust this data???

Is there an easy fix for this ?

[ACM]

Roland B
I cannot explain why you are not seeing any data for the dates and times you mention but from what I am seeing at my end using a 120 days Time Template that data does appear to be available (see screenshots in correspondence to your quotes)

29 Oct: no data between 14.29 and 18.44 (i.e. after subtracting 5 hours: between 09.30 and 13.44)

26 Oct: no data between 15.29 and 21.52 (i.e. after subtracting SIX hours: between 09.30 and 15.52)

We are not getting 120 days of stored 1-minute data - we are getting FOUR days

As far as I can see there are 120 days of data available (this includes some days which are holidays such as July 4th, etc as on those days some exchanges/instruments are trading)

I've been subscribing (and incidentally paying) for close to 4 years now, without ever getting any joy out of this feed anytime that I attempted to wrestle with it.

It is unfortunate that this has been your experience. I have been a subscriber for over 5 years and have had very few problems.

Is there an easy fix for this ?

I would suggest you contact eSignal's Support (via LiveRep) once they are online as they are best equipped to determine what the problem is and to offer solutions to resolve it.
Also from the context of your message it would appear that you are using one of eSignal's APIs. If that is the case then I would suggest that you post your message in the Desktop API forum.
Alex

Originally posted by Roland B
Hi,

Thanks for your prompt help in this matter. I really do appreciate.
Your trick does help - visually - to some extent. Programmatically, I continue to have serious trouble. If you try to write an application that should be able to cope with different datafeeds, it is rather cumbersome to deal with idiosyncracies such as the ones offered by eSignal. It so happens that I live 6 timezones away from the East coast. Between the eSignal application, my development environment, my various backup and other utilities, I spend a considerable amount of nerves setting dates/times, because I need a particular date/time to view data in eSignal, another to download or process it programmatically, another to do backups in order to be consistent with daily, monthly, yearly backup schemes and so on, simply because after years of development, eSignal developers have not managed to get a grip on one of the most basic features.
For instance, I have to switch date/time between realtime and history data, otherwise the number of days for which I request history data is incorrect. Date/time for realtime data is easy to convert. Never mind that all of this behavior changes for a few hours sometime after midnight EST (early morning in Europe) whith every new day.
This whole problem is shifted by one hour up/down twice a year with summer/winter times.
I've been subscribing (and incidentally paying) for close to 4 years now, without ever getting any joy out of this feed anytime that I attempted to wrestle with it.
At the latest after acquiring Quote.com, eSignal developers must have gotten a look at how simple a datafeed can be. For instance, Quote.com used to send a timestamp with every single record. This uses bandwidth but resolves any doubt about the correctness/latency of the data one is receiving. Compare this to the ridiculous addition of a timestamp within winsig - i.e. after reception of data.
The latest in this glory:
I am currently looking at QQQQ 1-minute data.
02 Nov seems OK
01 Nov seems OK
31 Oct seems OK
30 Oct seems OK
29 Oct: no data between 14.29 and 18.44 (i.e. after subtracting 5 hours: between 09.30 and 13.44)
now we change to winter time
26 Oct: no data between 15.29 and 21.52 (i.e. after subtracting SIX hours: between 09.30 and 15.52)
I'll spare you previous days.
We are not getting 120 days of stored 1-minute data - we are getting FOUR days - and who is to trust this data???

Is there an easy fix for this ?

[Roland B]

Alex

Your data seems OK.
Unfortunately this is not the case on my side of the ocean.
Just to show you that I am not entirely nuts, I attached a sample snapshot for October 26. This is of course taken from a new session, one day later.
I could include one for each of the first 116 days of the 120 day period. Only the last 4 days are OK.
You can see that this is taken from the app itself. The problem is not limited to the API. The data export shows the same shortfalls - it is not a 'viewing' problem.

[Roland B]

Alex

Just to be explicit, since the snapshot doesn't show this: it jumps from 16.29 to 23.15.
On October 29, it jumps from 15.29 to 18.44
On most days, it stops at 16.29.
Sep 27 it jumps from 16.29 to 23.02

There seems to be a more or less systematic problem.