Time zones in WSAPI

Products

• Rally On-Premise
• Rally SaaS

Issue/Introduction

How time zones are handled in the Web Services API (WSAPI)

The normalization that occurs inside the getters and setters for these attributes is largely transparent to the rest of the application (except for querying) and is not likely causing any issues. 

Previously, Rally took a provided date with time zone (using the user's time zone if none specified), shift it to the start or end of the day in the workspace's time zone, and then store the result. It was possible that the shifted date reflected a moment in time that no longer fell on the same day as the provided date. This broke the Ext grids.

Environment

Release:
Component: ACPREM

Resolution

The new behavior is almost the same except that when we shift the provided date to the start or end of the day in the workspace's time zone, we ensure that the shifted date always reflects a moment in time that falls on the same day as the provided date.

Example (based on the one in the API Versioning section of the WSAPI docs):

• The workspace's time zone is America/Los_Angeles (with an offset of -0700).
• The user creates an iteration with a start date of 2012-06-12T00:00:00:000-0400.

In WSAPI version 1.29 and below:

• The start date is adjusted to 2012-06-11T03:00:00:000-0400.
• The start date, as returned by the API, rendered in UTC: 2012-06-11T07:00:00:000Z.

In WSAPI version 1.30 and above:

• The start Date is adjusted to 2012-06-12T03:00:00:000-0400.
• The start Date, as returned by the API, rendered in UTC: 2012-06-12T07:00:00:000Z.