ForumsDevelopersTimezone problems with duetime
Timezone problems with duetime
| Author | Message |
|---|---|
|
safire |
I am seeing any issue with timezones and the duedate/duetime fields. Here's what I'm doing:
1. Verify my timezone -- I went to the account settings page and it shows my current local time (-5h -- Eastern), so that's correct. 2. Create a task on toodledo.com. Set the Due Date/Time to "Jan 30, 2012 at 10:00am". It shows up properly on the website as tomorrow 10:00am". 3. Retrieve the task via the api and I get back a unix timestamp for duetime=1327917600, which converted to a string is: duetime = 1327917600 GMT time = 2012-01-30 10:00:00 GMT EST time = 2012-01-30 05:00:00 EST (-0500) This seems wrong to me. Since the timezone on the website is set to -0500, then setting the due time to 10:00am should be interpreted as 10:00am EST, not GMT. Also, when I change my timezone on toodledo.com account settings page to -0400, and then look at my tasks, it still says the task is due at 10:00am. It should now read 11:00am because of the 1h change. |
|
safire |
FYI -- the Toodledo iPad application suffers from the same problem. Setting the time in the iPad app stores the time as relative to GMT and does not seem to pay attention to the timezone of the iPad.
|
|
Jake Toodledo Founder |
Times in Toodledo are stored as "floating times". 10:00am is always 10:00am regardless of where you are. We store the times as GMT. You do not need to do any conversions for timezones. Just display the time converted into a GMT string and it will always be correct.
The reasoning: If you are in California and make an appointment for 10:00am next month, and then travel to New York, the appointment is still set for 10:00am. It wouldn't be correct for your appointment to have been automatically rescheduled to 1:00pm. People would miss their appointments. The only reason why we need to know your timezone is so that we can send the alarms at the correct time. |
|
OrgTood |
Hi, thanks for your response.
That's incorrect behavior. To take your example, if I'm based in CA and setup an meeting for 10am, I expect it to be Pacific time. If I then have to travel to NY and then attend that meeting, it's not happening at 10am local time, it's at 1pm local time, so I expect my calendar application to give me the option to set the timezone. I change my *local* timezone to NY, and all my appointments shift to NY time. This is *standard* timezone behavior. Look at any calendar application, such as Microsoft Outlook. If you do not support this, why can I set the timezone on the account settings page? If all times are GMT, then there's no point in setting my timezone. |
|
safire |
So as I think about this, I think the feature you are going for is along the lines of an alarm clock as opposed to scheduling a meeting. I get up daily at 6am, so I set my alarm clock to 6:00am. If I travel to a different timezone, I still get up at 6am, thus it would be convenient if the alarm stayed at 6am.
If this is the case, then duetime and starttime should really not be stored in GMT time, and instead stored as seconds since midnight. Storing the duetime as a UNIX timestamp implies that the time is sensitive to timezone, and thus has been adjusted to account for local time. |
|
Jake Toodledo Founder |
In fact, we do store time as seconds since midnight in our database. We convert to GMT for the API, because our developers requested this. As I mentioned, we only request timezone so that we can send the alarm at the right time. Since a 6am alarm clock is always a 6am alarm clock anywhere in the world, we need to know where you are in order to send that 6am alarm at the right time. If we did not support alarms, we would not need to collect the timezone.
This is how times have been stored and implemented for the last 6 years on our website and we have never gotten any requests to have times automatically adjusted based on the timezone. In any case, now that you know how we store time, it shouldn't be hard for you to accommodate this in your app. I would argue that it is easier since you don't need to know about timezones. This message was edited Jan 30, 2012. |
|
safire |
Posted by Toodledo:
In fact, we do store time as seconds since midnight in our database. We convert to GMT for the API, because our developers requested this. Heh...got it. Not a big deal, I can adapt. I just wanted to make sure I understood how things are supposed to be working and that it is intentional. May I suggest a change to the documentation for the API as follows: duetime : A GMT unix timestamp for when the task is due. If the task does not have a time set, then this will be 0. If the task has a duetime without a duedate set, then the date component of this timestamp will be Jan 1, 1970. Only the time relative to midnight GMT is important. For example "Jan 13 8:00am GMT" means the task is due at 8:00am on the date of interest in the local timezone. This time must not be adjusted for the local timezone. Similar for starttime. Thanks! |
|
Jake Toodledo Founder |
Thanks. We will update our documentation.
|
|
bengt.mansson |
a related issue:
API doc says: duedate : ... When fetching from the server, it will always be noon. My experience is that it is not noon. It's midnight. Well, actually I've not checked the POST responses but in the iCal that I can import into Outlook it is midnight. That is bad because I want my week view focused on working hours. Is there any setting I've missed? |
|
Jake Toodledo Founder |
iCal and API have totally different specifications.
|
|
safire |
I can confirm that the time that comes back via "duedate" is noon GMT, not midnight. I figured that this is to minimize the likelihood that you'd have to pay attention to timezone if converting to a date, as for any timezone +/- 12 hours from GMT (which is almost all timezones), you'll still be in the same date.
|
You cannot reply yet
U Back to topic home
R Post a reply
To participate in these forums, you must be signed in.