Kevin, 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. >
Yep, it must be defined somewhere explicitly. > 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). > Yep > c) Store date/datetime values *must* be stored with an explicit timezone. > Nope > 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! > Moving the db is never a problem since it stores timezone within itself. Moving the server won't be problem only if it takes timezone from the db or always manually fixed after reallocation. > I am assuming that the development assumes that it is occuring in the > production environment (including timezone). > Yeah, it makes sense. -- Regards, Alexander
