Topic: game scheduling module

teppo wrote:

My WL profile only contains the hour difference to unspecified reference. This is not generally enough, since some countries in the zone go to daylight saving, while others don't. It might even be possible to find a place where the local time of two people both have same offset and use DST, but the start and end dates of daylight saving are not equal.

The problem is that we used USE_TZ = False in the django settings, which stores only datetimes into the database without timezone information. Changing this to USE_TZ = True all date information in the database has to be converted and many pieces of code has to be changed. See Migration. This was also partly discussed, see posts 2 and 3 in this bug. No one took the effort for this work so far.

Most people do not update their WL profiles to keep the daylight saving status up to date.

Yes, i believe most people do not look into their profile at all. Thats why the other bug report exists. For your project: Would it be helpful to show two sort of dates: "UTC/PROFILE_TIME (depending on your setting in your profile)"? So every user can convert his local time from UTC and may adjust his settings in wlprofile.

There is also a template tag called custom_date, which is used to for converting the dates of posts in the forums. Don't know if this will help you though: custom_date

Top

Quote

kaputtnik wrote:

The problem is that we used USE_TZ = False in the django settings, which stores only datetimes into the database without timezone information. Changing this to USE_TZ = True all date information in the database has to be converted and many pieces of code has to be changed. See Migration.

That is a huge mess. Fixing it properly would be fine, I agree. A quick and dirty workaround would be to add to the scheduling page:

• A big fat message saying that the scheduling assistant assumes my local time to be 12:34:56, with instructions what to do if the assumption is not right,

• Also quote all times in UTC, and encourage people to use those hours in discussions.

Both these would probably reduce the number of failed matches due to off-by-an-hour problem. They are not bullet proof and do not really fix the problem, but can be quickly tried.

EDIT: Is there are reason against asking the browser? This approach would not tell what the client's local time will be next week, though. (= still surprising results, if there is a DST change between day of agreement and the playday for some players but not all).

Top

Quote

EDIT: Is there are reason against asking the browser? This approach would not tell what the client's local time will be next week, though. (= still surprising results, if there is a DST change between day of agreement and the playday for some players but not all).

Actually we could predict if there will be a daytime saving

I guess the implementation would be kind of messy? Because that would require us to store the data about the DST in the db so that when displaying the available hours of the other players we can know when to change it. In which table should we add such data?

A big fat message saying that the scheduling assistant assumes my local time to be 12:34:56, with instructions what to do if the assumption is not right,

Also quote all times in UTC, and encourage people to use those hours in discussions.

Both these would probably reduce the number of failed matches due to off-by-an-hour problem. They are not bullet proof and do not really fix the problem, but can be quickly tried.

I think that's the best implementation we could have without adding any complexity for us. We could also pretty easily detect an error between localtime thanks to js and localtime calculated using the user's profil. And that way we would display a small error message to urge the player to fix the error if he confirm it is one.

Top

Quote

trimard wrote:

I guess the implementation would be kind of messy? Because that would require us to store the data about the DST in the db so that when displaying the available hours of the other players we can know when to change it. In which table should we add such data?

All modern operating systems store the daylight savings rules by country. If out user profiles contained country information, then there would be a clear path to fixing this properly. EDIT: In the above, I assumed that "storing TZ" refers to having the current "+-[num]" -data around as time zone information. If the timezones are stored as pytz, then the whole issue becomes a lot easier.

Apart from this remark, I agree to everything written here recently.

Top

Quote

GunChleoc wrote:

Not all users will be happy to provide country location in their profiles, so we can't rely on that.

Can we have "I love UTC" as an option to those who value privacy a lot? It is damn difficult to get the scheduling agent right without this information.

Top

Quote