* Server Time Incorrect * Time Zone Offsets Incorrect *

[giz]

Hi,


I am a user of, a poster onto, several forums that are based on V-Bulletin. I do NOT run any bulletin boards as yet nor am I involved in the Administration of any. I wanted to post this message in the V2 Forum, but because I am not a Forum owner the system would not let me.


There is a problem with the implementation of Time and Time Zones in this software. This problem shows even on THIS forum here.

It says >> All times are GMT. The time now is 11:50 PM. << which is incorrect. It is only 10:50PM GMT at the moment.



I have had a long discussion with a Forum owner, and I was directed to post the various messages here. The following is rather long, but I post it in full, so that you fully understand the problem, the reasoning, and maybe a hint at a solution. I have made a few minor changes to the wording to put them into context here. On the end is some other general stuff about Time and Time Zones that may also be of use...



======================================================================================



Originally Posted On another Server:



This is to inform that the Time Stamps on each message are all wrong.


The site says:

>> All times are GMT. The time now is 03:22PM GMT <<

but it is not that time at all. It is only 02:22PM GMT, a one hour difference.

The local clock time in the UK is 03:22PM, but in the Summer, which it is now, UK clocks work to British Summer Time, not GMT. BST is advanced one hour on from GMT.

British clocks only use GMT during their winter months. So right now it is 02:22PM GMT and 03:22PM BST. Other standard time zones should be reckoned from GMT, not from UK clock time.


GMT is actually an obsolete term. It applies only to UK clock time in the winter, and should not be used as the name for the reference point of time scales for determining time zone offsets. The correct term for the base time-scale is UTC (since 1971), and is based on atomic clocks. So, UK clocks show times that are UTC+0000 (GMT) in the winter, and UTC+0100 (BST) in the summer. Additionally 24-hour format time is preferred, so really it is 14:22 UTC (or 02:22PM UTC/GMT). Other time zones are quoted by their offset to UTC.

Eastern Standard Time is therefore UTC-0500 in their winter, and Eastern Daylight Time is UTC-0400 in their summer. They may, or may not, change from Standard Time to Daylight Saving Time, and back, on the same day as Britain does, but this doesn't matter because the time scale should be reckoned as to the offset from UTC, not from what is actually shown on a clock in Britain, because for half of the year British clocks are one hour different to that.


Confirmation of the correct UTC time can be found at: <http://tycho.usno.navy.mil/time_ann.ram> .
or from an updated URL at: <http://192.5.41.249:8080/ramgen/encoder/time_ann.ra> .


Perhaps you could change the time on the server to correct this error?




======================================================================================



I received this answer:



The server time is currently set up as correct east coast [local] time in the US. There's no way to change the vb script to reflect whether that's UTC-0400 [EDT] or UTC-0500 [EST] in the script unfortunately. You can always select an alternative time zone from your user cp though so that your time stamps will [appear to] be correct.


(My additional words are in [square] brackets)




======================================================================================



My reply:



I can see the reason, but that is very confusing for all other time zones outside of yours because other time zones make the change from Standard Time to Daylight Savings, and back, on a different day to you, and each has their local time zone calculated from GMT/UTC, not from 'clock time' in any particular country (even the UK clocks show GMT+0100 in Summer months, rather than GMT).


So, I could set my timezone as -1 to display correctly for now. but when you alter the server from Daylight Savings Time back to Standard Time (on some unspecified date), then suddenly my Times will be all wrong again, and then again when my country makes its DST change (a week or two later), the correction has to be done again.


For users in the Southern hemisphere, this is an even bigger problem, as they are adding an hour on to start DST at around the same time that the US is taking the hour off. The differing dates of transition will also mean this is a two-step process.


Anyone in Eastern Australia would be expecting to use GMT+0900 in their Winter and GMT+1000 in their Summer.

However what they find instead is very much more complicated:

* In the Austrlian winter they have to use GMT+0800 because the server is artificially advanced by one hour.

* If the US goes back to Standard Time before Australia moves forward to Daylight Savings Time, then Australian users have to move to +0900 when the US moves its zone, and then a few weeks later has to change to +1000 when Australia moves over.

* If Australia moves to Daylight Savings first, then users move only to +0900, because the server is already artificially advanced by one hour. When the US moves back to Standard Time (a few weeks later), Australian users then have to move to +1000.



This two-step situation is then reversed six months later:

* If the US goes forward to Daylight Savings Time before Australia moves back Standard Time, then Australian users have to move to +0900 when the US moves its zone (because the server is now artificially advanced one hour), and then a few weeks later has to change to +0800 when Australia moves (again only to +0800 because the server is artificially advanced one hour).

* If Australia moves back to Standard Time first, then users there have to move to +0900 which is correct. However when the US moves forward to Daylight Savings Time the server is now artificially advanced by one hour compared to where it should be, so users have to select +0800 again for the rest of the season.


This is very confusing to someone who was expecting to select +1000 in their Summer months and +0900 in their winter months.


It is a shame that the server could not be run on EST (UTC-0500) all year round; that is, make the server ignore EDT entirely.



[In fact, the technically correct solution is to run the server on UTC all year round, not on any sort of Local Time Zone. Most definately, the Server itself should not follow any sort of Daylight Savings rules].



The addition of a Tick Box: "Tick here to add one hour to displayed times during your summer months", on each users control panel would make the solution independant of the problem.


Just a few thoughts, and not meant in any way as a criticism.

Hopefully the above will make it clear to other users how it all works, as most people are extremely confused about time zones.

[giz]

Some general stuff I posted in a completely different Time Zone discussion:



You need to take a lot of care to get Time Zone implementations correct. Many out there on the Internet are seriously flawed.

Ask yourself whether you are just going to display the standard time of the target countries (this is easy to work out from published UTC offsets) or whether you want to show the actual time that would be on the clock on the wall in some building in that country - that is: also taking Daylight Savings Time offsets into account as well - this adds a LOT of complexity).




The term GMT is actually obsolete. It was replaced by UTC in 1971. UTC is an unchanging time scale that does not have a standard and daylight savings mode. It just carries on, one hour after the next. All other Standard time zones are calculated from this base, and the Standard time zones in some countries may have one hour added to them for Daylight Savings Time in their local Summer months.

So, GMT is actually only the Winter Time Zone of the UK, and is the same as UTC+0000. In Summer in the UK, BST (British Summer Time) is used, and this is the same as UTC+0100.

All other Standard time zones of the world are referenced to the UTC time zone, not to the clock time of the UK. Don't be caught out by setting your time zone to be relative to that of the wall-clocks in the UK as for 6 months of the year, your resultant time will be incorrect by one hour.

Some countries observe Daylight Savings Time and some do not. If DST is observed then it is always in their Summer months, and is done by adding an extra one hour to their clock time for about 6 or 7 months of the year. So, in the US Eastern Standard Time is UTC-0500, but Eastern Daylight Time is EST+0100 or the same as UTC-0400.

It just so happens that the US observes their Daylight Savings Time during the same months as the UK observes it, so in Winter the Eastern US has UTC-0500 and the UK has UTC+0000, and the Summer has the US on UTC-0400 and the UK on UTC+0100 so maintaining a 5 hour difference in the civil clock time of the two countries all year round. This is only spoilt by the fact that the changes forwards and back do not occur on exactly the same date, in the two countries, and so for a short while (a week or two) the observed clock-time difference may be 4 or 6 hours, depending on which country moves first and whether they are adding or subtracting an hour.

The Time Zone Names like EST have never been officially recognised anywhere, so EST could be Eastern Standard Time (US), European Summer Time, or Eastern Standard Time (Australia). The accepted way [ISO 8601] is to show Time Zones using a sign and four-digit representation, such as +0100 or -0500. The + is for all zones ahead of UTC (in general those East of Greenwich Meridian) and the - for those behind UTC (mostly West of Greenwich Meridian) [UTC is numerically equivalent to the old GMT]. The first two digits are for the hours and the last two are for the minutes. The minutes are important because there are a number of Time Zones that are 15, 30, or 45 minutes away from being a whole number of hours offset from the base UTC Time Zone.



The next major flaw in Time Zone implementations is in mixing up the Standard Time and Daylight Savings Time. There are some countries (mainly near the Equator) that do not observe Daylight Savings Time. However, any place that observes DST, usually observes it during their local Summer months, which are 6 months out of phase in the Northern and Southern hemispheres.

This means that the US typically uses DST from April to October or thereabouts, whilst Australia adds their extra hour between October and April. Again the two countries do not make the change on the sames dates as each other.



If you are printing a list of Times world wide you need to do this in several steps [This isn't a suggestion for VB, it was an answer to another problem, but the logic is useful here]:

1. Synchonise your computer to UTC and print this UTC Date and Time clearly.
2. Find the Standard time zone offset for each country/area. Print the Offset Value itself, and the resultant Date and Time (don't forget that on Monday late evening US, it is already Tuesday morning in Europe, and Tuesday afternoon in Asia) in two columns marked as 'Standard Time'.
3. Have a separate column for Daylight Savings Time, and only during the months that DST is being used do you actually put a Date and Time that is one hour ahead of that you printed in the Standard column.

The Standard Time column is quite easy to maintain because the actual offsets from UTC that each coutry uses as their standard time are rarely modified.

Printing the correct data for the Daylight Savings Time column will be much more difficult, as you will need access to a list of the actual dates and times (which are always quoted in UTC) that you need to start and stop adding the extra hour. Every country seems to use a different date, and dont forget that the Nothern and Southern hemisphere run approximately 6 months out of step. This information isn't usually available more than a year or so in advance, so you will have to regularly maintain and update this part of the system to keep up. In some countries the changeover time is well documented (last Sunday in March at 02:00 UTC, last Sunday in October at 02:00 UTC) but others the date various for political and/or religious reasons, and is far harder to keep updated [It may be better to just produce the Standard Times and let the local user add the extra hour during the months that DST is in force].


No-one ever takes an hour off of their Standard Time, it is always added, and always in the Local Summer time. Local Time is either Standard Time, or Daylight Savings Time (Standard Time+0100).

The Time Zone for any particular country is always quoted as the Standard Time, and this is always given as the offset to UTC.

So the Eastern US is quoted as UTC-0500. As the Eastern US is actually observing DST (EDT = EST+0100) at the moment, clocks there are actually showing times that are UTC-0400. Since clocks in the UK are on BST at the moment (and for another 2 weeks only), they are on UTC+0100 at the moment.


So: EST is UTC-0500 and EDT is EST+0100 (= UTC-0400),
and GMT is UTC+0000 and BST is GMT+0100 (= UTC+0100),
and NZT is UTC+1000 and NZD is NZT+0100 (= UTC+1100),
but NZ uses DST, 6 months in anti-phase to the northern countries.

The relationship is independant of the local time of any other country, and in particular the local time of the UK. It has to be so, because each country makes their change to and from DST on differing dates.





One final point is that dates like 01-12-2002 are not universally understood. In the US it is read as December 12th (MM-DD-YYYY), and in parts of Europe as 1st January (DD-MM-YYYY).

The US ANSI X3.30 standard, CSA Z234.5 in Canada, RFC 3339 on the Internet, and ISO 8601 elsewhere, uses YYYY-MM-DD as this does not look like either of the other formats and cannot be confused with any of them. The YYYY-MM-DD format retains the US style/ordering of MM/DD whilst merely moving the year information to the front, so that the date cannot be read as a European DD-MM-YYYY format.

I urge you to try this. Please note that no-one uses DD-YYYY-MM or MM-YYYY-DD or YYYY-DD-MM as their date format anywhere else in the world.



This is useful: <http://www.timeanddate.com/time/dst2002b.html> .



... and you thought that Time was simple?





======================================================================================



Conclusion:



Running a server on Local Time and adjusting the server for Standard and Daylight Savings time, means that a lot of servers out there are running with the time set one hour incorrectly, for half of the year. It would be nice if people could be persuaded from doing this, or you introduced a system where the VB software ran on UTC and the Forum Admin told the VB software what the local offset to UTC was in the server, then when the server time is changed, all the admin has to do is adjust the offset by one hour, to keep the VB software synchronised to UTC all year round.


For VBulletin I would rather like to see users run their servers on UTC all year round. Forum users would have the option to select their Standard Offset from UTC (just like the Time Zone relative to GMT box that is currently shown).

However I would like to see an additional Tick Box on the Users Control Panel that says >>> On the Day that your Time Zone changes to Daylight Savings Time, Tick Here to Add One Hour to the Displayed Time. Untick This Box When your Time Zone Reverts to Standard Time <<<.

This would put the solution to the problem into the hands of the user, and not have to rely on some heavy coding and a big look up table of all of the dates and times that each country changes to DST and back. This changeover data isn't available more than a year ahead in any case, so it would be a waste of effort to try to program for it on the server side.

One final plea. Please make the default date format YYYY-MM-DD as DD-MM-YYYY and MM-DD-YYYY are easily confused. No-one uses yyyy-dd-mm so the YYYY-MM-DD format is safe; see RFC 3339. It also retains the MM-DD ordering that the US is already using, so transition should be a lot easier.

It would also be nice if users could select whether they see times as AM/PM or as 24-hour format, as most countries outside of the US have been using the 24-hour format for several decades.



Hope this is useful to your programmers.

[ccd1]

How about using Swatch's funky internet time?

[giz]

I can see that this has been asked before:

http://www.vbulletin.com/forum/search.php?s=&action=showresults&searchid=454905&sortby=lastpost&sortorder=descending

Is it being fixed?

[Wayne Luke]

Since vBulletin 2.0 doesn't support daylight savigins time, there is nothing to fix.

vBulletin 3.0 does support daylight savings if the user selects it in their options.

[giz]

>> there is nothing to fix <<


Hmm,

At the bottom of the all of the screens on http://www.vbulletin.com/forum/ it clearly says:

-- All times are GMT. The time now is 03:30 AM. --


My computer is synchronised to the US Naval Observatory Atomic Clock. That says:

-- 2002-10-15 [Tue] 02:30:30 UTC/GMT --

[Wayne Luke]

Yes, and if you manually adjust your timezone offset to reflect daylight savings time in your area, it would be correct.

[giz]

>> Yes, and if you manually adjust your timezone offset to reflect daylight savings time in your area, it would be correct. <<


Um, not correct. The SERVER is being run on a different time zone to what you have TOLD the software you are running it on.


When it is 08:00 PM GMT your forum says that it is 09:00 PM GMT which is not correct. It has the words right there on creen IT IS NOW 09:00 GMT, but really it is NOT it is only 08:00PM GMT.

Try it, set your User Time Zone to GMT, look at the time on the forum screen, then go to: http://192.5.41.249:8080/ramgen/encoder/time_ann.ra and you will hear that the announced time is exactly one hour different to what you have on screen.


DST here has absolutely nothing at all to do with the message that I am trying to convey. Your server appears to be set to Daylight Savings Time in some US time zone whilst telling the software that it is still on Standard Time; that is you are running the server on, say, UTC-0400 whilst telling the forum that the server is on, say, UTC-0500. That is the problem that I am trying to highlight. The fact that all times and Time Zones are out by one hour because of some setting on the server.


In any case, the Northern hemisphere has DST from April to October, and the Southern hemisphere has it from October to April. I can't see anywhere that takes that into account, but that isn't the problem that I am highlighting.

[charlesa]

I'll add another wrinkle to this issue. I'm accessing a (vBulletin 2.2.7) server that's located in New Zealand. In Summer months (ie: now and for the next several months), they go from GMT+12 to GMT+13.

Even if the administrators were proactive and wanted to adjust the vB timezone offset on the server when Summer time began (they don't, they've just left it at the GMT+0 default, so they went from being 12 hours off to 13 hours fast), the UI doesn't support GMT+13 as a valid time zone.

I haven't looked at the PHP source, but I've got to imagine that adding a GMT+13 option to the pop-up would be a fairly easy fix to the 2.x server line.

[charlesa]

giz,

Have you received any indication from the administrators of this server to indicate that they understand that its timezone is currently set incorrectly for this installation?

I suppose in another ten days it'll be a moot issue if they're in the states. That's when the Summer time offset ends in the states and magically the current timezone offset will be correct again.

-C

[giz]

Umm. No, I don't think the problem was understood.

The Time Zone Offset will only be correct again, if the admin people of this server do actually change the internal time that the server runs on. Many people run their server on the same time zone all year round. So it may be that it stays like it is, all year round. If the admin people do change the time on the server, lets hope that they leave the VB time offset value alone, because moving that at all as well as moving the server time, will make it all wrong again. There is one problem, though, in moving the server time back (at 2 am local); this is, as the numeric hour will repeat again, someone posting 20 minutes after a post left at 01:50 will find it says 01:10 as the time stamp. That may confuse a few people, I suppose. I have been searching the web for fora that use VB. It seems that over three quarters of the sites that I have found all have there server time set incorrect, so this issue is not very well understood. If anyine has a copy of the relevant pages of the user manual, I am more than happy to rewrite the relevant parts to make this issue more clear.

[Steve Machol]

Originally posted by giz
Many people run their server on the same time zone all year round.

FWIW I run a daily cron job that synchs my server's time to a time server. As far as I know all reasonably well-managed servers are set up the same way.

[giz]

That is Correct; but the original point that I made some time back in these posts, was that the server running this forum is running on, lets say, EDT (Eastern Daylight Time), which is UTC-0400, but the VB software has been told that the server is actually running on UTC-0500 (which is EST, not EDT). This means that at the bottom of the forum screen it currently says that the time is 23:25GMT, when in actual fact it is only 22:25GMT.

I also wanted to point out that the word "GMT" is obsolete, and has been replaced by "UTC". UTC is numerically equivalent to GMT, but the word "UTC" is what should be used when specifying time zone offsets around the world.

[Steve Machol]

Yes, you've made your point. I know that the Developers are woking hard on the time issues in the next version of vB. Thank you.

[SkuZZy]

I just want to addon... I've had temendous trouble with the time zone offset as well. When I set it to pacific time +8, it would go backwards to -8 instead. All my users complained. So now my forums are just set to defeault GMT. I can't set it to pacific. If I go backwards then sure, it works, but it says the time is like, latvia or something.