Implement proper time zones support
I'm a developer and a longtime heavy user and huge fan. Up until now it has all been great. However, from now on, I have to deal with different time zones (TZs) and I noticed significant drawbacks.
I guess what I'm facing is a huge issue too if you are a frequent traveler, cross-border commuter, or employee in a global company spread across different TZs (online meetings, conferences...).
ISSUES
1. Moving back and forth between neighboring TZs (eg Spain-Portugal, UK-France) it's a nightmare because all the 'all day' tasks change their days (all marked days, birthdays, etc. show in the day before/after, even only for an hour difference). Of course, all the tasks with a specified time move one hour after/before. That's expected because the device TZ is offset from the TZ the tasks were created on. Your proposed way to deal with it is changing the account TZ on the web interface, and choose whether converting ALL the tasks times to the new TZ or keeping ALL of them as they are. However, there are tasks that should always be local time (wake up, have lunch, buy some milk, have dinner, own birthday and most 'all day' tasks...) and others that are on a specific time in a specific TZ (meetings, TV shows, release dates, national holidays, etc.). When crossing TZs the tasks marked as local time should never change their DateTime and always show at the time they were set while the tasks with an specified TZ should appear offset to the new device TZ (as it is now implemented).
2. Online meetings in other parts of the world give their times in their local TZ. When adding a new task, it's not possible to specify the TZ so that you have to convert it manually to the current device TZ before adding it. It would be convenient to allow the TZ to be specified. One of these TZs could be 'always local' (or simply 'local') as I suggested before. Another one might be 'current' (the device TZ).
Users should be able to select a DEFAULT TZ to be taken into account (when saving the DateTimes) in case they're not specifying it for new tasks. The options should be:
- device current TZ (as it is now)
- always local
- always
There shouldn't be an account TZ: there are users that need and use multiple time zones, so TZs are task-related and not user-related. But another way to bulk offset 'local' and/or 'not-local' DateTimes might be helpful.
I guess DateTimes are stored in UnixTime integers (no idea really). In this case, a boolean (whether the DateTime is local) should be stored as well. Device TZ offset conversions should be always bypassed in this case.
I guess what I'm facing is a huge issue too if you are a frequent traveler, cross-border commuter, or employee in a global company spread across different TZs (online meetings, conferences...).
ISSUES
1. Moving back and forth between neighboring TZs (eg Spain-Portugal, UK-France) it's a nightmare because all the 'all day' tasks change their days (all marked days, birthdays, etc. show in the day before/after, even only for an hour difference). Of course, all the tasks with a specified time move one hour after/before. That's expected because the device TZ is offset from the TZ the tasks were created on. Your proposed way to deal with it is changing the account TZ on the web interface, and choose whether converting ALL the tasks times to the new TZ or keeping ALL of them as they are. However, there are tasks that should always be local time (wake up, have lunch, buy some milk, have dinner, own birthday and most 'all day' tasks...) and others that are on a specific time in a specific TZ (meetings, TV shows, release dates, national holidays, etc.). When crossing TZs the tasks marked as local time should never change their DateTime and always show at the time they were set while the tasks with an specified TZ should appear offset to the new device TZ (as it is now implemented).
2. Online meetings in other parts of the world give their times in their local TZ. When adding a new task, it's not possible to specify the TZ so that you have to convert it manually to the current device TZ before adding it. It would be convenient to allow the TZ to be specified. One of these TZs could be 'always local' (or simply 'local') as I suggested before. Another one might be 'current' (the device TZ).
Users should be able to select a DEFAULT TZ to be taken into account (when saving the DateTimes) in case they're not specifying it for new tasks. The options should be:
- device current TZ (as it is now)
- always local
- always
There shouldn't be an account TZ: there are users that need and use multiple time zones, so TZs are task-related and not user-related. But another way to bulk offset 'local' and/or 'not-local' DateTimes might be helpful.
I guess DateTimes are stored in UnixTime integers (no idea really). In this case, a boolean (whether the DateTime is local) should be stored as well. Device TZ offset conversions should be always bypassed in this case.
Log in
to post a reply.