Timezone generalization about eear HOT 1 OPEN

To me, this is a big issue in general usability. It was designed for my purposes, so I hard coded timestamps locally and required the end-user to export data in UTC, which is the proper transport format timestamps should be in. However, going forward with a hosted solution, we might expect the data store to keep data in UTC (and our MDMS does). The user will want to select time locally. Therefore, options for specifying start and end times should also come with a locale indicator that defaults to what the user's current locale actually is. Using that information, the start and end times should be converted to UTC to match the data store (or converted to match whatever timezone the store maintains, which should be UTC!). On the GUI end, the dropdown list for specifying timezone should also default to the user's locale and maybe default to end being today and beginning being a month or week prior.

Using this framework, I don't think updating the codebase to handle general timezones should be too difficult, but it would be nice to see code for applications that actually do this so I can learn from their implementations.

from eear.