Hi there, I should have opened an issue to discuss, but we had another requirement for a FIX integration we have just started running in production with a large exchange, and this is our first pass at solving this, so I thought I'd submit upstream for feedback in case we've missed something.
The session we currently have with the exchange requires daily sessions but only during the week (Monday - Friday). We discovered when trying to define the session that including StartDay/EndDay properties in the session config made the session into a week long version so we wouldn't get the daily session end happening as required. To give this example again more concretely - with the following settings:
- StartTime: 08:00:00
- EndTime: 16:30:00
- StartDay: Monday
- EndDay: Friday
our session would start fine at 8am on Monday, but then at 4:30pm on Monday, the session would not logout, instead would stay connected right through until Friday at 4:30pm.
In looking at the config options provided by QuickFIX/J (https://www.quickfixj.org/usermanual/2.3.0/usage/configuration.html) we noticed they also provide a config setting called Weekdays which takes a comma separated list of day values with the semantics:
"For daily sessions that are active on specific days of the week."
this setting seemed to be exactly what we'd need, so this PR attempts to add this setting into QuickFIX/Go. We've updated tests I think correctly, though the tests in session_test.go were a little hard for us to follow, so it might be that we've missed something in there. We're in the process of testing out this branch on our side, so will convert this from a draft PR once we have some confidence on how it operates in practice.
Please note while making this change we also removed the panic inside TimeRange if given a nil location, and instead returned the error explicitly. This meant some minor changes in the parsing code in SessionFactory, and quite a few changes to tests, but we felt this change is more idiomatic for the situation where the nil location is something the caller could recover from by correcting the TimeZone value