Time Zone Conversion

Question

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 ?

Answer 1

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.

Answer 2

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.