test content
Logo
What is the Arc Client?
Install Arc
Timezone problems with the in-game event scheduler.
razor4lpha
Member, NW M9 Playtest Posts: 89 Arc User
There is a several years old bug with the in-game event system. Although the fix seems to be fairly incomplicated.
Whenever we schedule a new event and set it to 8pm on 26th, it gets saved as 5am ont he 27th.
Whenever I set up one to 10am it get saved as 7pm - 9 hours difference in both cases (I'm in CEST).
Whenever I open the event to edit anything, the time shifts again - and again.
One part of the issue is that the UI requires the player to set it up with the server's timezone
the second part is quite likely with the timezone being added to it on every save.
Please store it in UTC/GMT/Unix epoch or anything you prefer and let the UI side take care of the timezone alone, both on read and save.
It would be a pretty useful feature but these issues make it very cumbersome to use.
Whenever we schedule a new event and set it to 8pm on 26th, it gets saved as 5am ont he 27th.
Whenever I set up one to 10am it get saved as 7pm - 9 hours difference in both cases (I'm in CEST).
Whenever I open the event to edit anything, the time shifts again - and again.
One part of the issue is that the UI requires the player to set it up with the server's timezone
the second part is quite likely with the timezone being added to it on every save.
Please store it in UTC/GMT/Unix epoch or anything you prefer and let the UI side take care of the timezone alone, both on read and save.
It would be a pretty useful feature but these issues make it very cumbersome to use.
Tagged:
0
Comments
Setting up the event.
What it shows:
Editing the event.
There is not many place (if any) in the world using the same timezone of this server. This server uses PST the whole year. Its location (California) uses PST/PDT. That is about half a year they are not in the same time. At this moment, California is in PDT.
So, if it is a generic common issue, every guild leader would have such issue. By the way, our guild leader lives in UK.
If I bring up my programmer's hat, I would suspect the time data your game client transmits (time and your local time zone) is not read properly by the server. i.e. it does not understand your time zone to do the proper adjustment. It used the default (backup) time zone (PST) as your time zone (because it could not figure out your time zone) to calculate to store the data.
When the data send back to your PC (time and PST time zone), the client program does the proper adjustment (based on the data from server, not the original data).
In my case, it understood my time and time zone (Eastern time).
Changing how it stores the data will not help this issue if the server does not understand your time zone for whatever reason.
i.e. 'storing' is not the issue. Understanding the original time data is the issue.
I suspect your language is not English. Probably, the time zone string the game client transmit was not in English and the server could not translate it to something meaningful and failed. Then, it uses its 'default' time zone.
The +- N hour setting is only useful to get current time. Scheduling is about future time. Hence, I suspect the time zone string is needed and sent over to calculate the proper future time.
Storing the data in a not timezone dependent way like unix epoch saves the server the trouble of dealing with it at all, the timezone string does not even need to be sent, just the seconds since 1970 Jan 1, the client handles the timezone both ways according to the OS settings.
My time and timezone are correctly set, I'm experiencing this issue for years, on at least 3 computers.
Every other part of the game shows my time correctly: clock, non-player events, invoke, reset, etc.
My guildmates had the same / similar trouble with theirs, just different amounts resembling their own timezones.
I'm in CEST, thats UTC+2 - you say the server is in PST thats UTC-7, that is the exact same 9 hours difference my case shows, it shifts that amount on every save anytime I edit it.
No idea why it does not affect you in the Eastern timezone since it is a black box I can only see the results not the code, maybe a specific fix from their end maybe something else - but it still needs checking.
Using which time zone (TZx) to store does not matter. TZx can be UTC-0 or PST or EST.
What it matters is regardless which time zone is chosen for storage, a conversion is involved.
What it matters is who does the conversion from your local time to TZx.
The conversion could be implemented in the client side (your PC). Then, it does not need to send the time zone.
The conversion could be implemented in the server side. Then, it needs the time zone. The storage itself does not need the time zone but the time it stores needs the time zone to convert before it is saved to the database. i.e. the server stores all the time data after conversion for one time zone. In this case, PST.
I am not saying which implementation is better or more correct.
Based on the behavour of what your diagram shows, to "match" that behaviour, I theorized that it is done in the server side and the server did not use your time zone to convert properly. Obviously, it is just a guess.
Based on my guess,
you are in UTC+2, you want to set it to 8am Aug 26.
If it works, your 8am Aug 26 should be stored in the server as 11pm Aug 25 in PST after the time zone conversion (a).
When your PC read it, 11pm Aug 25 in PST was converted by your PC back to 8am Aug 26 in your time zone (b).
My theory is (a) does not work because the server does not understand your time zone but (b) works (done by your PC). I did not say you did anything wrong regarding your time zone setting. I was saying the server does not convert your time correctly because it does not understand your time zone. Again, just a theory, a guess.
So, your 8am Aug 26 local time was stored as 8am Aug 26 in PST because it does not do any time zone conversion.
When your PC read it, 8am Aug 26 in PST was converted by your PC to 5pm Aug 26 for your time zone.
Based on my guess, why does my time zone work?
It is because (a) works for my time zone.
Since you know its "current bad" behavour, to workaround it before they fix the bug, you can set the schedule to: 11pm Aug 25 so that it will be 8am Aug 26, your local time. Yes, you knew that already.
Whenever I was scheduling something there (though we rapidly decided to organize such things on discord for more flexibilty rather than using the messy ingame tool) I had bypassed the issue by substracting 9h (summer time) when I was creating my events. With this, the schedules are shown correctly in the calendar (as the right hour for your timezone) and the auto /g reminders that can be set are also triggering at the right time.
It may be specitific to countries using alternatively CEST/CET as both timezone are affected (at least for the french players ^^). Something like a stupid oversight on adding/substracting hours, a dateformat incompatibility between where the datehour is picked vs where the datehour is stored (or in the conversion formula) resulting in no conversion done.
From what I remember when I was using the guildevent in game tool :
The event creator seems to store the datehour h CEST choosen by the player as h PST instead of -9h PST. The event calendar seems to normally read the h PST stored as +9h CEST. The event editor doesn't seem to read the datehour stored but instead seems to pick the datehour displayed from the calendar as if it was h PST and then show it as +9h CEST.
Result, when you create an event starting the 31th August at 13h00 (CEST) in the interface, it may be saved as 13h00 (PST) then shown by the calendar as 31 August 22h00 (CEST) and if you try to edit it because you think you got the hour wrong, the editor may display the original start as 1st September 07h00 (CEST), and if you put it back to 31 August 13h00 (CEST) and save, you can read this sentence again...