[QFJ-378] SessionSchedule incorrectly handles Daylight Savings timezone change Created: 26/Nov/08  Updated: 02/Apr/15  Resolved: 05/Nov/13

Status: Closed
Project: QuickFIX/J
Component/s: Engine
Affects Version/s: 1.3.3
Fix Version/s: 1.6.0

Type: Bug Priority: Default
Reporter: Valery Trubnikov Assignee: Christoph John
Resolution: Fixed Votes: 11
Labels: None

Attachments: File sched.diff    

 Description   

This is a follow up for a recent issue we had with our production system.
Few days after daylight switch in USA (which happened to be on November 2nd 2008) our system disconnected one hour early from the exchange.
Here is a little test case to illustrate:

public void testSettingsWithStartEndDayWithDST() throws Exception

{ SessionSettings settings = new SessionSettings(); settings.setString(Session.SETTING_TIMEZONE, "America/New_York"); settings.setString(Session.SETTING_START_DAY, DayConverter.toString(Calendar.SUNDAY)); settings.setString(Session.SETTING_START_TIME, "20:00:00"); settings.setString(Session.SETTING_END_DAY, DayConverter.toString(Calendar.FRIDAY)); settings.setString(Session.SETTING_END_TIME, "17:00:00"); // mockSystemTimeSource.setTime(getTimeStamp(2008, Calendar.NOVEMBER, 2, 18, 0, 0, // TimeZone.getTimeZone("America/New_York"))); SessionID sessionID = new SessionID("FIX.4.2", "SENDER", "TARGET"); SessionSchedule schedule = new SessionSchedule(settings, sessionID); System.out.println(schedule); //November,2 -> Sunday doIsSessionTimeTest(schedule, true, 2008, Calendar.NOVEMBER, 2, 20, 0, 0, TimeZone.getTimeZone("America/New_York")); //November,7 -> Friday doIsSessionTimeTest(schedule, true, 2008, Calendar.NOVEMBER, 7, 17, 0, 0, TimeZone.getTimeZone("America/New_York")); }

*All times below are New York times.

For the sake of the example, our system starts every Sunday at 18:00 while actual trading starts (again every Sunday) at 20:00. Trading ends next Friday at 17:00. So, if you run the test as it is, it passes.
But if you uncomment "mockSystemTimeSource.setTime" the test fails, exactly for the same reason why our system shutdown trading one hour early.

The problem is with the way SessionSchedule converts END_* configuration into actual time point. Sunday November 2nd and Monday November 7th are both EST (winter time), BUT SessionSchedule actually goes back to previous Monday (October 27) which is still EDT (summer time) and thus converts to UTC incorrectly with 1 hour shift.

 Comments   
Comment by Valery Trubnikov [ 26/Nov/08 ]

As a sidenote - the problem seems to be even more complex for systems that do not go down every week but instead rely on quickfixj to handle trading start/stop.
If such system is configured with America/New_York timezone (or any other DST-aware tz), start/stop times in SessionSchedule will be incorrect after DST switch, because they are only calculated upon program start.

Comment by Mehul Patel [ 17/Nov/10 ]

This seems to be happening in 1.4 too.

Comment by Simon Wichtermann [ 06/Dec/12 ]

Here a diff/patch that should solve the incorrect daylight saving time change handling. (Changes in SessionSchedule, dep. on rev. 1008 and SessionScheduleTest, dep. on rev. 889)
It passes all unit tests in SessionScheduleTest, including some own additional tests and the tests of Valery Trubnikov.
But so far I could not test it "in real life" in my own environment (not beeing allowed to change system date/time). So there is no guarantee yet.
Hopefully someone else can test it soon...

Comment by Jörg Thönnes [ 16/Jul/13 ]

Thanks for the patch and the extensive test case.
Recent postings on the mailing list brought my attention to this bug.

Comment by tomi [ 29/Oct/13 ]

We have also been affected by this issue. Our current solution is to restart the system... twice per year. It is quite annoying as we are only allowed restarts on a weekend, so this will happen for a whole week until next Sunday.

Would be good to get fixed.

Comment by Tommy Hannon [ 05/Nov/13 ]

We also had to restart our applications yesterday, on Sunday, to avoid problems today.

Comment by Jon Beyer [ 05/Nov/13 ]

Also experienced this nasty bug today. Our application typically runs 24/7, and allows QFJ to bring the session up and down. But we did a rare restart this morning, and QFJ seemed to lose all sense of the session state. It was not easy to get back in sync with the acceptor.

Comment by tomi [ 05/Nov/13 ]

Hi Jon, just to help you out: you might need to set 'RefreshOnLogon=Y' in your config to have the session state working correctly on restart.

Comment by Christoph John [ 05/Nov/13 ]

Committed as rev1115. http://sourceforge.net/p/quickfixj/code/1115/
Thanks to Simon Wichtermann for the patch.

Generated at Wed Nov 27 03:04:47 UTC 2024 using JIRA 7.5.2#75007-sha1:9f5725bb824792b3230a5d8716f0c13e296a3cae.