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.