The article Last Updated - TimeZone Scenario describes the need to show/accept fields of DateTime data type in the TimeZone corresponding to each user (Current TimeZone) regardless of the time zone where these fields were originally generated.
Now, let’s suppose that a user in Tokyo needs to see fields of DateTime type in a time zone different than his current TZ. For instance, this could be the schedule of a conference that takes place in another country. The user sees the conference times in his time zone but he may also need to see them in the time zone of the country where they take place.
To solve this scenario, the application must have TimeZone Support enabled and allow the user to select the time zone of the country where the conference takes place from the user’s interface.
Suppose that the conference takes place in New York. Its time zone is TimeZones.New_York. The application must have an event, similar to the one below, that changes alternatively from the user’s time zone to New York’s time zone, and whose code invokes the SetTimeZone method.
Event "Change time zone"
if DateTime.GetTimeZone() <> TimeZones.New_York
// &PreviousTimeZone is a variable based on the TimeZones Domain that is used to hold the value of the default user time zone.
&PreviousTimeZone = DateTime.GetTimeZone()
Last Updated - TimeZone Scenario