API timezone handling not consistent with web interface
(closed account) says:
Hi,
My timezone is "Pacific/Auckland" (in RTM settings and on my computer). That's currently GMT+12:00 but when DST was in effect a couple of weeks ago, it was GMT+13:00.
Back then I created a task in the web interface and did not specify a time, just 27 March.
Today, when I use the API to retrieve the task its timestamp is 26 March 11:00. It appears that RTM interpreted my entry as "27 March local midnight", and then converted to UTC by deducting the 13 hours offset at the time. Please let it be known that that is not what I meant when I left out the time, and I see this as a workaround on RTM's end. I didn't enter a datetime, I entered a date without a time.
Today (15 Apr) I retrieved the task with the API, and I get the UTC timestamp (needing 13h added to not be a day too early) but when I add the current offset of my timezone (12h, as retrieved via API from settings.timezone) I'm short by an hour, and end up being a day early at 23:00. If I re-enter the task in the web interface it gets saved with the current - and therefore _currently_ correct offset.
a) My only workaround I see is for every task retrieved through the API I have to convert to the local time _that was effective at time of creation_. Is that intended?
b) The correct timezone information must be attached to the task itself somewhere, because the web interface still shows the correct date even now that 13h offset have been shortened to 12. I guess the inconsistency I'm referring to in the topic is the fact that the web interface shows a different date (the one I entered) to what I can calculate from the information retrieved through the API.
c) I can't even help myself with task.has_due_time because the date I'm getting is wrong. I truly believe that if has_due_time is False, then the API should always return the date entered. In fact if has_due_time is False then really "due" should not have a time component in it at all. I realize that could break existing software so maybe always return the date entered at midnight? The UTC time of what my local midnight meant at the time the task was created is definitely not very useful imho.
Cheers,
Danny
My timezone is "Pacific/Auckland" (in RTM settings and on my computer). That's currently GMT+12:00 but when DST was in effect a couple of weeks ago, it was GMT+13:00.
Back then I created a task in the web interface and did not specify a time, just 27 March.
Today, when I use the API to retrieve the task its timestamp is 26 March 11:00. It appears that RTM interpreted my entry as "27 March local midnight", and then converted to UTC by deducting the 13 hours offset at the time. Please let it be known that that is not what I meant when I left out the time, and I see this as a workaround on RTM's end. I didn't enter a datetime, I entered a date without a time.
Today (15 Apr) I retrieved the task with the API, and I get the UTC timestamp (needing 13h added to not be a day too early) but when I add the current offset of my timezone (12h, as retrieved via API from settings.timezone) I'm short by an hour, and end up being a day early at 23:00. If I re-enter the task in the web interface it gets saved with the current - and therefore _currently_ correct offset.
a) My only workaround I see is for every task retrieved through the API I have to convert to the local time _that was effective at time of creation_. Is that intended?
b) The correct timezone information must be attached to the task itself somewhere, because the web interface still shows the correct date even now that 13h offset have been shortened to 12. I guess the inconsistency I'm referring to in the topic is the fact that the web interface shows a different date (the one I entered) to what I can calculate from the information retrieved through the API.
c) I can't even help myself with task.has_due_time because the date I'm getting is wrong. I truly believe that if has_due_time is False, then the API should always return the date entered. In fact if has_due_time is False then really "due" should not have a time component in it at all. I realize that could break existing software so maybe always return the date entered at midnight? The UTC time of what my local midnight meant at the time the task was created is definitely not very useful imho.
Cheers,
Danny
emily (Remember The Milk) says:
Hi Danny,
I was wondering if you would you mind re-posting this over on the API Developer Mailing List?
That's the best place to post about the API, as it's monitored by the API devs.
Thanks!
I was wondering if you would you mind re-posting this over on the API Developer Mailing List?
That's the best place to post about the API, as it's monitored by the API devs.
Thanks!
(closed account) says:
P.S.: "rtm.time.convert" (which no I wouldn't want to call for every single task anyway) is also affected by this bug: If I feed it the retrieved UTC date that is 13h off, it will add my _current_ offset which is 12h and the day stays wrong.
(closed account) says:
Hi Emily,
will do this now - thank you for the prompt response.
Cheers,
Danny
will do this now - thank you for the prompt response.
Cheers,
Danny