Home Forums Tickstory Lite General Discussion Closing/opening time inconsistency

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • pete7
    Participant
    Post count: 5

    Hello guys,

    First of all I really, really like Tickstory Lite. Great product, great job!

    Now, as much as I like it, I think there might be a little inconsistency in the way opening/closing hours of the market (or TZ conversion on the Tickstory side) are considered.
    I have downloaded and exported into CSV tick data for GBPUSD for 2010. Then I changed TZ (I am using R to do this) to EST. What I found was that during 2010 there were 34 Sundays with openings at 16.00 and 18 with opening at 17.00. Checking the same data with default UTC setting yield generates the same problem = there are ticks where there shouldn’t be. Those problematic Sundays include for example 2010-03-14, 2010-03-21.
    2010-03-14 was the day in which EST -> EDT change happened and this is probably the case, but the problem exists with UTC data which shouldn’t differ as UTC doesn’t consider DST change.
    So when exporting data for 2010-03-14 the market should open at 22 UTC not 21 as the data indicates, am I right ?

    On a side note: Have you considered adding an option to choose different “export to file” folder than MT4 or default installation folder for those user that don’t use MT4 ?

    Reagrds,
    P.

    pete7
    Participant
    Post count: 5

    Funny thing: if i choose EST+7 as the TZ when exporting data 14.03.2010, the ticks start to arrive at 00 which is a valid time, but it’s not +7 but +8 shift from UTC [+7 from EDT]. The other thing is that I selected from 14.03.2010 to 14.03.2010 and the generated data shows 15.03.2010 from 00:00 to 03:00, which surely is not 14.03.2010.

    This and probelm and the one in the post above are easy to replicate and indicate serious problems with dates and timestamps. Tickstory team can you please elaborate on them – this can mean that anyone exporting data with UTC is gettin wrong timestamps?

    Regards,
    P.

    imported_tickstory
    Participant
    Post count: 1479

    Hi Pete,

    Dukascopy data has some known “anomalies” but generally speaking is a reliable source. Perhaps this thread helps explains more: viewtopic.php?f=2&t=580. If this doesn’t answer your question, perhaps you can highlight what you believe is wrong with GBPUSD on 14/03/2010? We’ve viewed the data in the Tickstory data viewer in GMT and can’t see issue. If you’re saying there’s only a problem when the time-zone is shifted, are you able to show the problem in a screenshot? Also, have you ensured that you’ve got all the latest Windows updates applied – Tickstory utilises the time-zone information from your Windows installation.

    Thanks.

    pete7
    Participant
    Post count: 5

    Thanks Tickstory for answering.
    The problem is: export tick data for GBPUSD for 07-03-2010, UTC – it starts at 17.00.
    Then export tick data for GBPUSD for 14-03-2010, UTC – it starts at 16.00.
    As UTC is “DST-free” starting hours shouldn’t differ.

    Regards,
    P.

    imported_tickstory
    Participant
    Post count: 1479

    Hi,

    Attached is a screenshot of the GBPUSD data for 14 March 2010 as shown in the Tickstory Data Viewer. It starts at 21:00 GMT.

    Regards.

    pete7
    Participant
    Post count: 5

    Hm, strange. Did you export it as UTC ?

    imported_tickstory
    Participant
    Post count: 1479

    Yes we did. I think it would be more helpful to record the exact steps that are causing your problem and then post accompanying screenshots. That way it’s easier to understand and reproduce the issue if there is one.

    Thanks.

    pete7
    Participant
    Post count: 5

    Export settings and results: link.

    Regards,
    P.

    imported_tickstory
    Participant
    Post count: 1479

    Hi Pete,

    That matches the UTC data we have in our screenshot. It starts at 9pm UTC. What’s the issue with this?

    Thanks.

Viewing 9 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic.