Thank you for sharing the information. By now I convert time to local format as well as current timezone offset and store it in the database, for example:
2009-03-03 01:15 -05:00 (EST) --> 2009-03-03 14:15 +08:00 (China Standard Time) DST begins (jsut an example)... 2009-03-03 03:15 -04:00 (EDT) --> 2009-03-03 15:15 +08:00 (China Standard Time) .... 2009-11-03 01:15 -04:00 (EDT) --> 2009-11-03 13:15 +08:00 (China Standard Time) DST ends (jsut an example)... 2009-11-03 01:15 -05:00 (EST) --> 2009-11-03 14:15 +08:00 (China Standard Time) With luck, I get timestamp from system, not user input. So event system generates the same local time, I have the timezone offset to distrigulish them. On Jul 20, 8:28 am, Streets Of Boston <[email protected]> wrote: > Be careful with DST and such. I work for a company that trackstime > (timecards, scheduling etc.). Handling DST properly is tricky. > > The method Date.getTime() is timezone-less. It is a 'universal'time, > a *timestamp*, just atimewithout a definition of place/location! It > returns the number of milliseconds since midnight on 1/1/1970 UTC > (=GMT without DST). Wherever you are, and assuming your device's clock > is set properly, the Date.getTime() must return the same value, since > it is timezone-less. > > However, if you want to know the *time-of-day* at your location, then > you add a place/location to the universaltime: > Whattime-of-day is it where I am on the timestamp returned by > Date.getTime()? > The place/location is expressed in timezones. > > E.g. Date.getTime() returns 15:00 7/19/20098 GMT. I am in Boston, > which is in timezone GMT-5. This means that thetime-of-day in Boston > is 10:00 7/19/2009 GMT-5:00. Note that timezones are not always in > hours, then can even be in chunks of 15 minutes, e.g. 20:45 7/19/2009 > GMT+5:45. > > On top of this, there aredaylightsavinglaws/regulations (DST). > Every region has its own laws regardingdaylightsaving. You can have > multiple DST definitions in one timezone and they can change over the > years. In the USA, then can vary per county, for example. > > The problem with DST is that you'll get non-existingtime-of-days and > double-countedtime-of-days. > E.g. in most countries, the DST changes at 2:00 am. > When moving the clock forwards, thetime-of-day 2:15am does not exist. > What do you do if you get such input? > When moving the clock backwards, thetime-of-date 1:15am happens > twice. Which one of the two do you choose if you get such input? > > In short: > When dealing with timestamps, like the one returned by Date.getTime(), > don't worry about timezones, DST, etc. > When dealing withtime-of-day, be careful. Try to figure out the > corresponding timestamp and store this value. > > On Jul 19, 8:44 am, Cheng Zhong <[email protected]> wrote: > > > Hi all, > > > What will Date.getTime() returns in a region withDaylightSavingTime > > enabled? > > > Does this function returns a DSTtimeor not? > > > I call Date.getTime() in a place with DST (such as U.S.), and convert > > it to a localtimein China (no DST), I get a wrongtime(one hour > > ahead of localtimein China). How can I fixed this problem? > > > Maybe I didn't tell tings clearly, but we don't use DST in China... I > > don't understand DST very well. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
