Play Now Login Create Account
illyriad
  New Posts New Posts RSS Feed - 15JUL11 - Patchnotes
  FAQ FAQ  Forum Search   Register Register  Login Login

Topic Closed15JUL11 - Patchnotes

 Post Reply Post Reply Page  12>
Author
GM ThunderCat View Drop Down
Admin Group
Admin Group
Avatar
GM

Joined: 11 Dec 2009
Location: Everywhere
Status: Offline
Points: 1987
Direct Link To This Post Topic: 15JUL11 - Patchnotes
    Posted: 15 Jul 2011 at 18:08

TOURNAMENT COMPLETED
Tournament III - Harnessing the Elementals, has now completed and the winners have been announced here!

FACTION DESCRIPTION ADDED
The Wen Kun Dynasty now have their full faction description in place.

APPOINTING SITTER INGAME MAIL 
Now contains details on the correct procedure for returning to your own account.

MOVING CITIES (AGAIN)
We've changed the rules on moving cities (again).  In a recent patch we said that any incoming units to your town would prevent you from moving.  However this introduced the unexpected appearance of a bug if diplomatic units were inbound to your town, but not yet visible to your town.

Therefore you can now move your city even if diplomatic units are inbound to it.  The units will arrive as expected on the expected schedule and return home as if the player had not moved. Incoming Military Units, however, continue to prevent a player from moving their town.

TOURNAMENT SQUARES
The Tournament Squares will - even after the Tournament has ended - continue to act as PvP zones (as they did before the tournament).  On these squares, Alliance comradeship, NAPs, Confederations etc do not apply.  These squares will be marked as "Ancient Battle Sites" on the map.

SERVER TIME
Server time has been synced with global time; you make need to refresh your browser for the top clock to refresh.

CHAT TIMES
Both global and alliance chat have been changed to accurately report the server time stamp on the chat rather than than trying to do an overly complicated calculation involving the difference between your local time, the server time, the drift between the two and the various time zone offsets.

ALLIANCE CHAT
Alliance chat now includes the date as well as the time of the chat (in-case your alliance isn't too chatty) 

Back to Top
HonoredMule View Drop Down
Postmaster General
Postmaster General
Avatar

Joined: 05 Mar 2010
Location: Canada
Status: Offline
Points: 1650
Direct Link To This Post Posted: 15 Jul 2011 at 21:34
Originally posted by GM ThunderCat GM ThunderCat wrote:


CHAT TIMES
Both global and alliance chat have been changed to accurately report the server time stamp on the chat rather than than trying to do an overly complicated calculation involving the difference between your local time, the server time, the drift between the two and the various time zone offsets.

ALLIANCE CHAT
Alliance chat now includes the date as well as the time of the chat (in-case your alliance isn't too chatty) 



What would be really awesome is switching the server from GMT to UTC (no more DST).  Then there would be parity between UNIX timestamps, Javascript timestamps/1000, and server time (assuming no drift/server kept in touch with time servers).  Time conversions between local, canonical, and server time would be a lot simpler.
Back to Top
GM Stormcrow View Drop Down
Admin Group
Admin Group
Avatar
GM

Joined: 23 Feb 2010
Location: Illyria
Status: Offline
Points: 3260
Direct Link To This Post Posted: 15 Jul 2011 at 21:43
Originally posted by HonoredMule HonoredMule wrote:

Originally posted by GM ThunderCat GM ThunderCat wrote:


CHAT TIMES
Both global and alliance chat have been changed to accurately report the server time stamp on the chat rather than than trying to do an overly complicated calculation involving the difference between your local time, the server time, the drift between the two and the various time zone offsets.

ALLIANCE CHAT
Alliance chat now includes the date as well as the time of the chat (in-case your alliance isn't too chatty) 



What would be really awesome is switching the server from GMT to UTC (no more DST).  Then there would be parity between UNIX timestamps, Javascript timestamps/1000, and server time (assuming no drift/server kept in touch with time servers).  Time conversions between local, canonical, and server time would be a lot simpler.

Don't get me started on time, HM...  I mean, please don't.  Mostly for TC's sake Wink


Back to Top
Manannan View Drop Down
Postmaster
Postmaster
Avatar

Joined: 22 Mar 2011
Location: Mystical Mists
Status: Offline
Points: 559
Direct Link To This Post Posted: 15 Jul 2011 at 23:30
Originally posted by GM Stormcrow GM Stormcrow wrote:

Don't get me started on time, HM...  I mean, please don't.  Mostly for TC's sake Wink

I know I shouldn't do this but its just too good an opportunity to pass up...

There just isn't enough time in the day to discuss the time! LOL
Doesn't look good... doesn't look bad either!

"Manananananananananan, so long Sir, and thanks for all the fish." ~ St.Jude
Back to Top
Selwyn View Drop Down
New Poster
New Poster


Joined: 20 Nov 2010
Status: Offline
Points: 25
Direct Link To This Post Posted: 16 Jul 2011 at 02:12
/me confused ... GMT & UTC  are the same ? DST is different? and is why in UK because of DST we are at GMT +1 ......stick to ZULU you civilians , its what keeps the worlds military safe lol
Back to Top
GM Stormcrow View Drop Down
Admin Group
Admin Group
Avatar
GM

Joined: 23 Feb 2010
Location: Illyria
Status: Offline
Points: 3260
Direct Link To This Post Posted: 16 Jul 2011 at 02:32
Originally posted by Selwyn Selwyn wrote:

/me confused ... GMT & UTC  are the same ? DST is different? and is why in UK because of DST we are at GMT +1 ......stick to ZULU you civilians , its what keeps the worlds military safe lol

Ah, no... GMT and UTC are subtly different, and to quote wikipedia on this one... "UTC is closely related to Universal Time and Greenwich Mean Time (GMT) and within informal or casual contexts where sub-second precision is not required, it can be used interchangeably."

But we deal with sub-second precision every single second (apologies for the bad pun), and generally run to a thousandth of a second for timing of things.

Seriously, time is srsbzns, and needs careful handling.

Regards,

SC

PS. Having said all this, I'm all in favour of a move to UTC via NTP...


Edited by GM Stormcrow - 16 Jul 2011 at 02:33
Back to Top
GM Stormcrow View Drop Down
Admin Group
Admin Group
Avatar
GM

Joined: 23 Feb 2010
Location: Illyria
Status: Offline
Points: 3260
Direct Link To This Post Posted: 16 Jul 2011 at 02:39
Back to Top
Selwyn View Drop Down
New Poster
New Poster


Joined: 20 Nov 2010
Status: Offline
Points: 25
Direct Link To This Post Posted: 16 Jul 2011 at 03:02
make me look up wiki lol ...The UTC time zone is sometimes denoted by the letter Z—a reference to the equivalent nautical time zone (GMT), which has been denoted by a Z since about 1950. The letter also refers to the "zone description" of zero hours, which has been used since 1920 (see time zone history). Since the NATO phonetic alphabet and amateur radio word for Z is "Zulu", UTC is sometimes known as Zulu time. This is especially true in aviation, where Zulu is the universal standard.[12] This ensures all pilots regardless of location are using the same 24-hour clock, thus avoiding confusion when flying between time zones...

guess we agree sort of on ZULU lol
Back to Top
scottfitz View Drop Down
Forum Warrior
Forum Warrior


Joined: 22 Apr 2010
Location: Spokane WA USA
Status: Offline
Points: 407
Direct Link To This Post Posted: 16 Jul 2011 at 04:06
I reject your silly notion of time! Besides if I am not asleep (which is rare) Ia am playing Illy!
Back to Top
HonoredMule View Drop Down
Postmaster General
Postmaster General
Avatar

Joined: 05 Mar 2010
Location: Canada
Status: Offline
Points: 1650
Direct Link To This Post Posted: 16 Jul 2011 at 05:03
Despite Wikipedia's pearls of wisdom, I have yet to see UTC used to reference anything but "base" or "canonical" time with no timezone or DST offset.  http://www.diffen.com/difference/GMT_vs_UTC actually does a better job of explaining what each actually is as well as how they're commonly used.  Technically, the server is currently not in GMT or UTC, but BST (British Summer Time).  Nevertheless, GMT is often carelessly used to mean GMT + DST without clarifying whether DST is included  or not (and potentially meaning either).

What the UK calls British Summer Time, and Europe calls European Summer Time, the rest of the world generalizes as Daylight Savings Time (DST).  In either case, when it is in effect is subject to local laws (I think sometimes even to regions smaller than a country).  It is a nightmare indeed--people running Linux systems will notice "tzdata" getting updated virtually every month because of constantly changing and often complex DST calendar rules in various locales.  Since DST doesn't have a single global schedule, that means for many the difference between local and server time actually changes 4 times a year.

In MS world, it is typical to use timestamp formats that specify offset (without clarifying from which combination of locale and DST state it's derived, or without clarifying the actual offset in numeric value).  It also seems common to refer to GMT (or localized variants such as AST, PST, etc.) without bothering to specify whether that's with or without DST offsets applied.  There are now a whole new set of abbreviations to specify local timezone with DST (i.e. ADT, PDT, etc.), but I've never seen them come up in any of my various (often UNIX-centric) jobs.  Far too commonly developers just throw something up that sounds right and then deal with various minor time-related bugs without ever realizing the cause.

This is one of those areas where UNIX's philosophy of keeping it as stupidly simple as possible (seconds since midnight, Jan 1st, 1970) worked out absolutely brilliantly and leaves no room whatsoever for ambiguity, while making all manner of operations on dates also stupidly simple (even converting to and from well-defined localizations).  Localization issues don't go away, but they're well isolated from everything else from data formats and storage to calculations and communication.

----

I can understand TC's frustrations with time...Javascript internally uses UNIX timestamps (sort of, it counts milliseconds at integer precision instead of seconds) but its date parsing/handling/etc capabilities are all black box tools that assume a date string represents time in the browser's local settings.  It's possible to generate UTC or localized date string parts, and to alter an existing date using UTC date parts, but creating a date representing some other locale requires applying manual offsets and thus requires that the developer's know all there is to know about timezone and DST rules just to calculate an offset--all to produce a date object whose internal value is basically wrong everywhere.  Alternatively, the server can just calculate a dumb delta between server and user time and send it for the browser to use (which is what Illyriad does) but that value doesn't change when the factors that defined it do (until the user reloads the browser), nor can the browser predict when it's tracking a date which will end after such a change.

The only reliable fix is to start bandying 3 values: server time, local time, and true time--and also to use a system whereby you can store proper dates and generate date strings using arbitrary offsets without those offset dates gumming up the works where actual storage, calculations, or comparisons are taking place.  But even that still leaves a gaping hole to patch, because none of it answers the questions "is the server on BST time now?" and "when will the server jump an hour?"  It's up to the programmer to track and, when necessary, compensate for these issues.

Butler actually has a very robust date string parsing/generating system using AI techniques (code writing code--"generators" and "parsers" for specific formats defined by format strings compatible with http://php.net/manual/en/function.date.php but also accepting an arbitrary offset to apply to its output).  And it needs it more than Illyriad does, when trying to help the user manage local-time schedules for handling server-time-sensitive operations.  For now I consistently use and store UTC-backed local time, while parsing/generating "screwy time" (local plus server difference) using the time delta Illyriad calculates.  But that delta isn't very accurate for tracking upcoming dates, especially as network congestion fluctuates, and I'm supposed to be showing to-the-second launch timers and such.  Also, that value can't be directly used since it includes local timezone data which should not be part of a local date (because numerically it is in UTC--and must be when used for more than display purposes).  I actually have to correct it to:
 - Illy-provided offset + ((new Date).getTimezoneOffset() * -60000)
in order to produce correct UTC dates (which then provide correct local view using non-UTC getDatePart() methods).  I imagine Illyriad does similar somewhere, but haven't seen where.  In the near future, I'll be looking into pulling the http date header out of every AJAX request (excluding some that intentionally hang waiting for output) to update my own server offset and use a "rolling average" of the last 10 values.  Even then I won't trust that DST changes will occur smoothly, without ever giving people dates that are off by an hour.  Everything would be a lot simpler if one never had to deal with date values which are not UTC, or with date strings which are neither local nor UTC.  Server drift would still exist, but being a handful of seconds at most, methods which calculate it can simply discard larger date parts (like hours and sets of 30 minutes--remember those crazy Newfies do GMT -3:30 hours).
Back to Top
 Post Reply Post Reply Page  12>
  Share Topic   

Forum Jump Forum Permissions View Drop Down

Forum Software by Web Wiz Forums® version 11.07
Copyright ©2001-2016 Web Wiz Ltd.