15JUL11 - Patchnotes |
Post Reply | Page 12> |
Author | ||
HonoredMule
Postmaster General Joined: 05 Mar 2010 Location: Canada Status: Offline Points: 1650 |
Topic: 15JUL11 - Patchnotes Posted: 16 Jul 2011 at 05:07 |
|
I guess the root of the problem all comes down to separating content from presentation.
|
||
HonoredMule
Postmaster General Joined: 05 Mar 2010 Location: Canada Status: Offline Points: 1650 |
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). |
||
scottfitz
Forum Warrior Joined: 22 Apr 2010 Location: Spokane WA USA Status: Offline Points: 439 |
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!
|
||
Selwyn
New Poster Joined: 20 Nov 2010 Status: Offline Points: 25 |
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 |
||
GM Stormcrow
Moderator Group GM Joined: 23 Feb 2010 Location: Illyria Status: Offline Points: 3926 |
Posted: 16 Jul 2011 at 02:39 | |
Oh, and from the Illyriad Vaults, this.
|
||
GM Stormcrow
Moderator Group GM Joined: 23 Feb 2010 Location: Illyria Status: Offline Points: 3926 |
Posted: 16 Jul 2011 at 02:32 | |
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 |
||
Selwyn
New Poster Joined: 20 Nov 2010 Status: Offline Points: 25 |
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
|
||
Manannan
Postmaster Joined: 22 Mar 2011 Location: Mystical Mists Status: Offline Points: 576 |
Posted: 15 Jul 2011 at 23:30 | |
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!
|
||
Doesn't look good... doesn't look bad either!
"Manananananananananan, so long Sir, and thanks for all the fish." ~ St.Jude |
||
GM Stormcrow
Moderator Group GM Joined: 23 Feb 2010 Location: Illyria Status: Offline Points: 3926 |
Posted: 15 Jul 2011 at 21:43 | |
Don't get me started on time, HM... I mean, please don't. Mostly for TC's sake |
||
HonoredMule
Postmaster General Joined: 05 Mar 2010 Location: Canada Status: Offline Points: 1650 |
Posted: 15 Jul 2011 at 21:34 | |
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. |
||
Post Reply | Page 12> |
Tweet
|
Forum Jump | Forum Permissions You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |