MDEntryTime/Date fields aren't parsed correctly when Daylight Savings time is in effect

FIX.4.4 protocol has MDEntryTime (273) and MDEntryDate (272) to specify the time/date of market data entries.

When you are trying to parse a market data incremental refresh (MsgType=X), and you have a MDEntryTime of "13:30:00" it will parse it using the UtcTimeOnlyConverter, but it'll parse the time relative to the January 1, 1970 date. As a result, in the summer you'll end up with times being off-by-one, bc January is not during DST.

The real way to parse the MDEntryTime is to combine it with the MDEntryDate, so that if the other field is present it should use it and then it'll have the right date and will have the DST value calculated correctly.

The workaround, for now, is to of course parse the entire date/time combined string together.

Here's the example portion of a message that'll break this (see fields 272/273):
8=FIX.4.4
35=X
...
268=1950
279=0
269=5
55=YHOO
270=23.6400
272=20070820
273=13:30:00.000
279=0
....