Day Light savings time problem.

Questions about MultiCharts and user contributed studies.
bowlesj3
Posts: 2180
Joined: 21 Jul 2007
Has thanked: 227 times
Been thanked: 429 times

Day Light savings time problem.

Postby bowlesj3 » 10 Mar 2008

I am not sure where the problem actually resides. However here is that is happening. Maybe someone is having the same problem.

I am using MC with IB's Traders Work Station.

I test the times on the bars for various reasons. One is to place vertical dotted lines on the chart as markers for the start and end of the trading day.

Okay it works fine except for the week when {{{during the last 2 or 3 years}}} the governments changed things so that daylight savings time (both fall and spring) is in effect a week earlier. Here is what happens during this week.

I set my PC clock to the correct time (the time that the radios and TVs are telling me that is the correct time). I have to disable Dimension 4 which is the automic clock program since it still has the old times from the automic clocks around the world which do not change during this week. A sneeaky way around this is to change my time zone on the computer but lets keep it simple and just say I disable the D4 progrem and change my PC clock manually.

So now my PC clock has the correct time to match the radio and TV etc. MC now displays the correct time on the 1 minute bar chart scale at the bottom of the chart. However the time stamps are still 1 hour behind this thus matching the automic clocks. This would make sense except I do not have the TWS time stamps checked as yes in the quote manager (neither historical nor real time). So, for some reason, MC is getting the old time before the Governments decided to jump to daylight savings time one week early (in other words it is getting the Automic clock times). To clarifiy this it is getting the automic clock time when I use the Time_S command on the 10 second bars or the Time command on the 1 minute bars. Yet MC is displaying on the chart the PC clock time (whatever I choose for the PC clock).

Okay so now I have to change my EL code to test for a time which is one hour earlier to get those nice vertical dotted lines in the correct place and leave my PC clock set properly to what the radio and TV are telling me is the correct time.

Grumble Grumble! As far as I am concerned it is the Government's fault. They should have left the daylight savings time the way it was for so many years rather than starting it a week earlier as they have the last 2 or 3 years. I figure the person who thought of this just wanted to start playing golf earlier in the year with that extra hour of daylight coming sooner. Makes sense to me. However I don't play golf and we just had about 50 centimeters of snow over the weekend. They must live in Florida. Now that is a good idea. I will move there and I will be so happy I won't care about this problem. :-) On a more serious note, I guess I will feed a parameter called AtimeToBtimeMinutes (actual time to bar time minutes offset) into the system. Anywhere it is appropriate this will correct any misscalculations by doing a 60 minute offset when needed. The parameter will normally be zero but for 2 weeks out of the year it will be +60 where the PC clock time is 60 minutes ahead of the bar time.

bowlesj3
Posts: 2180
Joined: 21 Jul 2007
Has thanked: 227 times
Been thanked: 429 times

leaving it as is.

Postby bowlesj3 » 11 Mar 2008

I have decided the easiest way to handle this is leave the computer running at the normal old automic clock daylight savings times rather than follow the governments latest changes. The offset is still needed but use in less places (less programming work). The time scale will be wrong for one week. I can live with that.

bowlesj3
Posts: 2180
Joined: 21 Jul 2007
Has thanked: 227 times
Been thanked: 429 times

Good web sites

Postby bowlesj3 » 11 Mar 2008

There are some good web sites on this topic. Google is amazing. Just type a question like one you would ask a friend and it will likely out do them giving you more info than you need before they can say 2 words. Anyway, it turns out that what my Government did is fairly common. It makes sense that the automtic clock sites will and should stay consistent since many different local governments will do different things. So my approach above is the simplest for now and involves some manual work arounds for 2 weeks of the year. Maybe later I can do it better, shift my time zone for those two weeks and put in more code to make use of the 60 minute offset parameter fed through the GV.

bowlesj3
Posts: 2180
Joined: 21 Jul 2007
Has thanked: 227 times
Been thanked: 429 times

The best solution.

Postby bowlesj3 » 18 Mar 2008

In the end I think it is best to adjust the time zone on your computer first so most items are correct then include an offset parameter to be submitted somewhere (such as a GV) to allow the code to make adjustments where needed (maybe a series of these to make it easier to document where these offsets are taking place if there is more than one). Then when the automic clock sites make their day light savings time shifts you can set the time zone on the computer back to normal and set the offset parameter(s) to zero for the majority of the year.

At present if I do this my IB trades come in with a time stamp one hour ahead (meaning if my time is 16:00 hours then their time is 17:00 hours). That is okay. Eventually it should shift back (I think???). This year is different for some reason since the normally only one week where the clocks get out of alignment in the spring is lasting more than one week.


Return to “MultiCharts”