And, as I said, I care about being _able_ to put time data on disk in local time (NOT UTC + offset) with all local time quirks. That doesn't have to be default, or trivial, but must remain possible.
Melanie Teravus Ovares wrote: > As I said in IRC, > > I'm firmly of the mind that we should make it easy to ensure that all > time data is consistant. I think the easiest way to do this is to > standardize on UTC. Whatever time zone your server hardware/OS is in, > you can always get UTC from it. > > I am not averse to having a 'super advanced OMG what the heck are you > doing' option to set a UTC offset above and beyond.. but I really > think it should be UTC by default across the board. > > Best Regards > > Teravus > > On 1/18/09, Gerhard Dünnebeil <[email protected]> wrote: >> When dealing with time you have to distinguish between the time the >> machines work on and the time the users sees. >> >> Introducing time zones at the wrong level also introduces a lot of >> confusion as you (the developer) always have to know with which time >> zone you currently deal. >> >> MySQL isn't really an issue as you can set the time zone you want to >> work in with the session. >> >> So my thoughts: >> Use UTC internally; that includes storage of data, machine to machine >> communication, .... >> Use the users time zone when (and only when) communicating with the >> user, which is mainly when times are displayed. >> >> This is easier as one might think, as using UTC as the time base is >> available in all standard OS (windows, linux, ...) these days. There is >> no need to set a system clock to UTC as long as the system knows the >> offset to UTC. >> >> Gerhard >> >> >> Dahlia Trimble wrote: >> > With the err... um... inevitable future event when the LL grid opens >> > the doors to full interoperability, and given that their large >> > customer base is accustomed to using "SLT" (California time) and all >> > the scripts that may assume SLT, shouldn't we weigh that option over >> > UTC or GMT or CUT or whatever it's called these days? >> > >> > On a side note, regions running in virtual machines may have less >> > control over the system clocks than regions running in a regular >> > machine. I'd like to suggest that region times could be configured in >> > OpenSim.ini and/or set by a central server using ntp or a similar >> > protocol. >> > >> > On Sun, Jan 18, 2009 at 10:32 AM, Charles Krinke <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> > There are some issues coming up about timezones and grids. It >> > seems that events, scripts, web interfaces and other things are >> > affected by timezones. It gets a bit more complicated when one >> > considers that our mysql logic uses local time with calls that >> > involve NOW(). >> > >> > Some folks feel that all the time on all the sims on all the grids >> > should be set to UTC, and that is a reasonable approach. >> > >> > Others feel that a UGAIM should set the timezone for a grid and >> > tell the sims connected to that UGAIM what timezone they are in >> > and what time it is at the time of grid registration with a UGAIM, >> > and that is also a reasonable approach. >> > >> > There is more. But, rather then just declaring what I might feel >> > to be the answer, I would like to seek a consensus that is best >> > for OpenSim and any comments or suggestions are greatly >> > appreciated to this "timely" subject. >> > >> > Charles >> > >> > _______________________________________________ >> > Opensim-dev mailing list >> > [email protected] <mailto:[email protected]> >> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> > >> > >> > ------------------------------------------------------------------------ >> > >> > _______________________________________________ >> > Opensim-dev mailing list >> > [email protected] >> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> > >> >> _______________________________________________ >> Opensim-dev mailing list >> [email protected] >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev > > _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
