Alexander, If I understand you correctly, you're saying: a) *two* timezone conversions need to be covered: datastore <-> system <-> UI In general, the datastore and system will have the same timezone, but this must not be *assumed* to be the case.
b) Stored date/datetime values need not (must not?) have an explicit timezone, as long as the datastore has a timezone (which it is assumed that all values in the datastore are stored in). or are you saying c) Store date/datetime values *must* be stored with an explicit timezone. As long as the following can be handled - a system is built to assume all actions happen in a single timezone, and hence does not try and handle events across timezones (like a multinational meeting scheduler would). It must not fall over if the datastore is moved (for convenience) to another country - think: you currently host your webapp in the USA, but a cheaper provider appears in India and you choose to move... if you're not careful, lunch time is no longer in the middle of your day! On Tue, March 15, 2011 12:09, Alexander Krasnukhin wrote: > My point is that it's very common that development and production are in > different timezones. I am assuming that the development assumes that it is occuring in the production environment (including timezone). > But I don't think UTC is a good choice. Try to write correct SQL queries > developing in GMT+7 for production in GMT+2 while db stores everything in > UTC. Happy testing! > > My point is that there must be one single place to take "system common > time > zone" from. And it should be as close as possible to the data - db is the > perfect choice. With this approach even xml files must have "time zone" > property so they will show correct time in GMT+2 and GMT+7. > > Well, it's just my thoughts. >
