Currently Online

Latest Posts

Topic: game scheduling module

teppo
Joined: 2012-01-30, 09:42
Posts: 355
Ranking
Tribe Member
Posted at: 2017-08-29, 06:41

trimard wrote:

Gunscheoc Mhh I m not sure it would change much for me. I don t use django a lot for the logic. User.wlprofile.time_zone seems good enough this module. But maybe my implémentation isn t right

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.

If this is not addressed, there will be off-by-hour irritation, especially if the original agreement was done under pressure (tournament => must do, despite difficulties to find suitable spots).

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


Top Quote
kaputtnik
Avatar
Joined: 2013-02-18, 20:48
Posts: 1765
Ranking
One Elder of Players
Location: Germany
Posted at: 2017-08-29, 08:41

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
trimard
Joined: 2009-03-05, 22:40
Posts: 200
Ranking
Widelands-Forum-Junkie
Location: Paris
Posted at: 2017-08-29, 16:15

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.

Or maybe we could change the date in the scheduling menu directly? That way people will change it on the right moment? Even better. We could find the right timezone from the user depending on his current timezone in js, and automatically update it everytime they go in scheduling?


Top Quote
teppo
Joined: 2012-01-30, 09:42
Posts: 355
Ranking
Tribe Member
Posted at: 2017-08-30, 06:46

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).

Edited: 2017-08-30, 06:55

Top Quote
kaputtnik
Avatar
Joined: 2013-02-18, 20:48
Posts: 1765
Ranking
One Elder of Players
Location: Germany
Posted at: 2017-08-30, 08:58

teppo wrote:

That is a huge mess. Fixing it properly would be fine, I agree.

Some history:
The website has started with Django 1.2 which had no time zone support. Time zone support was added in Django 1.4. Because of fear the time zone support will break several things and lack of developers, the website runs a very long time with Django 1.3.x. Then it was managed to update it from 1.3.x to Django 1.8 to have an up-to-date Backend. T'his was a huge step and took me around an half a year to apply all changes and adjust the code basis. Since the website had run without any problems at this time, the decision was made to set USE_TZ = False. So i'ts not a huge mess, it's just not optimal face-wink.png

  • 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.

+1

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).

I think the time zone problem should be fixed on server side and will create a bug report for this.


Top Quote
trimard
Joined: 2009-03-05, 22:40
Posts: 200
Ranking
Widelands-Forum-Junkie
Location: Paris
Posted at: 2017-08-30, 14:11

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
kaputtnik
Avatar
Joined: 2013-02-18, 20:48
Posts: 1765
Ranking
One Elder of Players
Location: Germany
Posted at: 2017-08-30, 18:30

trimard wrote:

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.

Go for it face-smile.png

Here is the Time zone bug report


Top Quote
teppo
Joined: 2012-01-30, 09:42
Posts: 355
Ranking
Tribe Member
Posted at: 2017-08-30, 18:37

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.

Edited: 2017-08-30, 18:55

Top Quote
GunChleoc
Avatar
Joined: 2013-10-07, 15:56
Posts: 3057
Ranking
One Elder of Players
Location: RenderedRect
Posted at: 2017-08-30, 18:52

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


Busy indexing nil values

Top Quote
teppo
Joined: 2012-01-30, 09:42
Posts: 355
Ranking
Tribe Member
Posted at: 2017-08-30, 18:58

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.

Edited: 2017-08-30, 18:58

Top Quote