# Time Zone Conversion

I use Mathematica to administer my share depots. The depots contain shares of many different time zones. I update the depot values several times a day. My problem is that Sidney, Australia, (it might be that today here is already tomorrow there) gives me another date value than the stock exchange in Frankfurt:

For example:

FinancialData["AX:WBC", "LatestTrade"]


gives at this moment

{{2015, 3, 17, 16, 10, 0.}, 38.54}


whereas

FinancialData["F:VOW", "LatestTrade"]


gives at this moment:

{{2015, 3, 17, 19, 29, 0.}, 248.804}


"AX" stands for "Australian Stock Exchange",

"WBC" stands for "Westpac" (One of the of the few succesfull banks worldwide),

"F" stands for "Frankfurt Stock Exchange" and

"VOW" stands for a well known manufacturer of beetles.

I have written some overly complicated code to "unify" different time zones. Once in a while it functions. Once in a while I comprehend it the very next day.

### Questions

• Is there an easy way to convert Sidney-time to Frankfurt-time ?

• Complicated and a major bonus attached: How do I account for the different bank hollidays ?

• Getting rich brings you unexpected problems, doesn't it? :) Mar 17, 2015 at 21:33
• Getting poor, as I recently observed in Comodoro Rivadavia, too :)
– eldo
Mar 17, 2015 at 21:52
• WolframAlpha["Sidney time to Frankfurt time"] Mar 17, 2015 at 22:32
• It's elementary. Just stick with terrestrial time.
– Jens
Mar 18, 2015 at 2:01
• I enjoy your clever titles, but might I suggest that you include some indication of the subject matter, perhaps something like Time Zone Conversion: A Theory of Non-Relativity? Mar 18, 2015 at 14:55

TimeZoneConvert (V10)

With version 10+, we can use TimeZoneConvert. It requires that we convert our date list to a DateObject:

TimeZoneConvert[DateObject[{2015,3,17,16,10,0}, TimeZone->11], 1]


The result is also a DateObject. A DateObject has an advantage over a date list because the object carries an explicit time zone specification.

DateList

If we are using version 9 or earlier, or there is some application-specific reason to continue to use date lists, then time zone conversion is a bit awkward:

Block[{$TimeZone=11}, DateList[{2015,3,17,16,10,0}, TimeZone->1]] (* {2015, 3, 17, 6, 10, 0.} *)  The TimeZone->1 option that we supply to DateList indicates that we wish the output to be expressed as a date within GMT+1 ("GMT" follows Mathematica usage, as opposed to "UTC"). DateList will assume that the input parameter {2015,3,17,16,10,0} is in the current time zone. We use Block[{$TimeZone=11},...] to set the current time zone to GMT+11, our input time zone.

Since date lists do not carry their associated time zones internally, it is the application's responsibility to provide the correct input and output time zones for each operation. That, plus the awkward specification of the input time zone, prompts me to advise the use of DateObject whenever possible.

Standard Time Zone

I concur with @Jagra's advice to choose a standard time zone (probably GMT) for use throughout the application instead of converting back-and-forth between time zones repeatedly. This will reduce the number of call sites where erroneous conversion can take place. It also makes the use of date lists much more viable since their lack of explicit time zones becomes less relevant.

Update: Obtaining Time Zone Offset Information (V10)

So far, all of the examples have used time zone specifications which must (almost) always be specified as offsets in hours from UTC. In Version 10, we can use the entity framework to obtain such offsets. For example:

$city = Interpreter["City"]; QuantityMagnitude[$city["Sidney"]["TimeZone"]["OffsetFromUTC"], "Hours"]
(* 11 *)

QuantityMagnitude[$city["Frankfurt"]["TimeZone"]["OffsetFromUTC"], "Hours"] (* 1 *)  These expressions correct for daylight savings time. The results shown are for if the expressions were evaluated in early March 2015. In late August of 2015, these same expressions return 10 for Sidney and 2 for Frankfurt. Note that these expressions require internet connectivity to operate properly (i.e. $AllowInternet must be True).

Thus the TimeZoneConvert example from above could be expanded to use the entity framework to obtain time zone information:

$city = Interpreter["City"]; TimeZoneConvert[ DateObject[{2015, 3, 17, 16, 10, 0} , TimeZone -> QuantityMagnitude[$city["Sidney"]["TimeZone"]["OffsetFromUTC"], "Hours"]
]
, \$city["Frankfurt"]
]


This example also shows that TimeZoneConvert will optionally accept a city entity as a time zone specification, while DateObject will not.

Beware that entity framework calls tend to be very expensive so in a real application it would be a good idea to cache the values so obtained.

• +1 from me. I haven't had the opportunity to study the new DateObject paradigm. Great introduction. Mar 18, 2015 at 19:57
• Thank you so much !!! That's exactly I was looking for :)
– eldo
Mar 19, 2015 at 18:11
• I think there is one important detail to note: if I understand this correctly from the documentation, the time zone specification in v9 is just an offset of a given (fixed) number of hours, not a real geographical time zone.The problem is that the offset between two fixed location can change during the year because they may be adopting daylight saving time at different dates, or one of them may not be adopting it at all. So a conversion done this way will not always work... am I getting this right? Is this any better in v10? Aug 30, 2015 at 0:08
• @GiacomoCiani You are correct. I added a section that shows how to obtain time zone offset information using the V10 entity framework. Aug 30, 2015 at 4:35
• Great! Thanks... now I just need to move to v10 :-) Aug 31, 2015 at 13:31

Perhaps just an extended comment...

I recommend that you convert everything you need to track everything to GMT, but this begs a larger question, which I suggest includes your second question.

To trade effectively anywhere (and it seems everywhere) one needs a way to keep track of all trading and trade accounting implementation details - both static and active data. This can get unwieldy if you don't get or develop a clearly thought out data model to hold and manage all such details. The image below provides an example of a structure to do this.

One could implement something like this in something like MySQL, as persistent objects in an OOP approach, or probably in some clever Mathematica data structure (which might make for its own interesting question). I'll remain agnostic at this point.

The entities depicted provide a high level of abstraction, which makes them quite versatile.

The image I've posted should support a comprehensive portfolio management and trading system.

Martin Fowler's book, Analysis Patterns, informed much of the design (especially the Strategy layer).

The Accounting layer should support any type of actor that interacts with the defined domain (the OP, brokers, exchanges, ...). Its designed has endeavored to replicate the functionality of a double entry accounting method.

The Instrument layer should cover just about all the kinds of instrument data and details to support trading.

I only offer this data model as a prompt to assist the OP in thinking deeply about everything they need to operate effectively in the world in which he has expressed interest.