Note that time+timezone are not sufficient to accurately define the time, under certain circumstances.
The problem is that time as a target has a subjective component: in the event of an unexpected DST change, in which direction would the original provider of the time expect the time to move in relation to UTC. This appears most prominently with calendar software, wherein a user creates a meeting in the future and invites other users to the meeting, then the DST start/end is shifted by the local government for some unfathomable reason. In this event, the meeting may have moved from 9am on the initiators local time, to 8am, relative to UTC. In this case, choosing the UTC- translated time was the wrong choice - the meeting is still 9am for everyone involved except the computer. Precisely what can be done in this scenario isn't clear, the only obviously correct course is to notify the user as soon as possible of the problem so that they can make an informed choice on what to do with regard to the meeting time. In general however, as long as all your users are in the same timezone, you are less likely to go wrong by using the localtime rather than UTC offset - because local time is what they're working in as well. As soon as you involve multiple timezones and the future, the problem actually becomes indeterminate. Most solutions simply ignore this possibility and cheerfully cause chaos for everyone when their retarded government decides that 3 weeks of extra daylight is worth screwing over half the IT industry. </rant> The common solution to this is, as noted, to use a fixed UTC/GMT offset for any given user, and trust in them to corret it when DST hits them (or ignore it entirely, like they normally do). Fewer sites actually get the correct timezone from the user and attempt to adjust for DST correctly. In my most recent site, we simply ignored the problem entirely and declared that we had a "site clock" that everything happened by. Experience thus far demonstrates that people pretty much don't care, and will adapt to a shifted time without complaint unless the time is particularly important to them, so long as you liberally make use of links to timeanddate.com for static event times to make it easy for them to plan. On Apr 5, 12:25 pm, "Bobby Impollonia" <[EMAIL PROTECTED]> wrote: > Always store everything as utc. That ensures that the data you are > working with is clearly defined and consistent. If you want the times > to be displayed (or input) according to the user's timezone, that is a > detail of the presentation and UI, not of the underlying data. > > On Thu, Apr 3, 2008 at 1:05 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > So far I've been storing time stamps in my mysql database just using > > datetime.datetime.now()....but I'm wondering if that's the right thing > > to be doing? > > Am I perhaps better off storing everything in utc time? How do other > > people deal with this? I noticed that postgresql seems to have > > datatypes for storing date-times including the timezone but mysql > > lacks this. So perhaps the best strategies are different for > > different databases? > > > What method are people using to discover the timezones of their > > clients? > > > Thanks! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
