Hello, I am using MetaApi for building one of my projects (you may heard of that API),
and when integrating a new server into my project I need to input server timezone and DST switch timezone. I guess I figured out how to find server timezone, but I need help with finding timezone according to which DST switch happens on the server.
I hope you can help me with this one, thanks in advance!
What does a DST switch mean? Daylight savings time?
yes DST means Daylight saving time
Hi, and thanks for clarifying. I had not heard of MetaApi, but for benefit of others who may be curious. I have added a link to a high level description of what MetaApi is and how it is supposed to work.
I have an interest in this subject overall, since in 2019 one of my projects (for a very large company) was to manage the build, installation, testing and initial pilots for a RPA initiative undertaken by a global service supplier. RPA is robotic process automation, and my involvement was to question the old fashioned strategy of the vendor of using what they referred to as “screen sraping” and to convince them to favour the use of persistent API (applications programming interface) in close cooperation with the supplier of the target database so that they did not break the system in operation, and need to modify the “scraper” every time the database provider made a change to its application release (which was frequent).
Now on to your question.
I have worked extensively with global datacentres and migration of applications to such. It is not a simple case of assumption. First of all, every server uses a time server from which to synchronise its “time and date”, but on the server side, it is a corporate decision whether to automatically update daylight savings time on the application servers, or whether to do that manually. It is over a decade ago that I experienced manual updates, so it is safe to assume that all (or at least most) of the application servers in the world will use UTC as the base time clock, and the application will adjust itself accordingly.
For many traders, it is frustrating to decide to use a broker service only to find that you cannot change the date format, nor the “time reference” for which time period data is added to the database. For years I have only used services that show me the GUI graphical data in my timezone of reference (which is GMT between 3rd week of October and 3rd week of March, and GMT+1 hour between 4th week of March and 2nd week of October (what we call British summer time).
Anyone planning any IT support work, flights, holidays spanning the weeks of these biannual events will relate the frustration and extra planning they need to do to make sure that passengers don’t turn up an hour too late, and other time critical issues. It has often fascinated me how such systems have been set up because not every country in the world uses the same weekend to transition from winter time to summer time. And you can get very confused when it comes to the southern hemisphere. For six months of the year, Australia east coast (Sydney and Melbourne) are 9 hours ahead of UK time but for the other six months they are 11 hours ahead. Why is this when we only add 1 hour for summer time? Because our summer is their winter, so on the same weekend the Brits add an hour and the Aussies subtract one. And to make matters worse, Perth is 3 hours behind Melbourne - it’s a wide country, as California is 3 hours behind New York.
My suggestion is that you add your new server for a trial period and ignore the DST switch, since it only happens twice per year. For all underlying instruments except crypto currencies, the global trading week starts around 10pm Sunday UK time and ends around 02:00 Saturday UK time. That is very little of an annual data set that would be delivering “incorrect data”, and use the first release of the application you are planning with some user note to the effect that "DST switch times are not catered for, so don’t trade the day before and day of DST switch, or manually check the data. If you get concerned about the timezone of the DST switch, it may be different on the server than it is on the client data feeds anyway. Start with UTC (GMT half of the year) and state that this is what you have used.
I hope this has been of help, but look forward to suggestions from other forum members who may have application-specific knowledge of how DST is treated by any of the major data source businesses.