When you see a time field displayed on a web page it may not be the time that either you or the owner of the page expect it to be. This is the World Wide Web and pages on a web site need not all be stored on the same server and these servers can be located anywhere in the world. Also the time field displayed can be calculated either from the time on the server or from the time stored on your computer as the visitor to the site. In either case the web page may be using a fixed offset from that time to attempt to represent a particular timezone but the result may not be what is expected.
As a result of all of these things the exact time displayed on a web page has very little meaning in many cases except when comparing the time shown against multiple entries in (for example) a forum or other dynamic page.
Let's consider a couple of instances where time is displayed on a page and consider what can effect the time so that it does not display as intended.
First let's consider the time display on our home page where the local time in Sydney, Australia (where Ask Felgall is based) is displayed. This time is calculated from the time you have set on your computer (what is known as client side processing). First GMT time is determined using the time on your system and your computer's timezone offset and daylight saving indicator. The time is then set ten or eleven hours forward from that time depending on the setting in the script that indicates whether we are on daylight saving time or not.
The correct display of the time here depends on your computer being set to the correct local time for your location, it depends on your having correctly set your timezone and daylight saving indicator, and it depends on my remembering to set the daylight saving flag in the script when daylight saving starts (usually late October) and ends (usually late March). If any of these are set wrong then the wrong time will be displayed. You have control of the time settings on your computer and so with the correct setting you should get either the correct time or be one hour out (if we have forgotten to update the script).
Now let's consider the time displayed against entries on a Bravenet guestbook or forum which are actually located on a server in the USA. In this instance the times shown are calculated based on the time shown on that server (server side processing) and a timezone offset that the forum script allows us to enter, the server timezone is being changed to reflect US daylight savings time (we have no idea when this starts and finishes) and the changes that we would make manually to the timezone offset to attempt to get the correct local time to display (in our case the time in Sydney). Unless we (as the web service owner) are located in the USA (or somewhere else that goes on and off of daylight savings time on the same dates as the USA) we not only need to remember to adjust the timezone setting at the start and end of daylight saving time where we are but would also need to adjust the timezone to undo the daylight saving time change that the server applies. As most of us outside of the USA do not know the correct dates for these changes it makes it difficult to get the settings right all of the time.
In this instance the displayed time can be up to two hours out from the correct time (assuming that the server is set to the correct time and timezone for where it is located - if that is wrong then it can be even further out). You (as a site visitor) have no way of correcting the time display at all and all we (as site owner) can do is to change the timezone offset whenever we become aware that it was wrong. All else is in the hands of the hosting service.
Although the examples that I have used are for times displayed on specific sites, the same situation applies to all other times that you see displayed on the web. They are all subject to similar calculations either client side or server side and hence even with your computer's time set correctly may still be an hour or two different from that intended by the web site owner.
When it comes to email the situation can be even worse as there may be several mail servers involved as well as the computer that sent the email to you (or is the recipient of your email). The time that shows on an email when you receive it may bear little resemblance to the time that the email was actually sent particularly if you are in different time zones.
This article written by Stephen Chapman, Felgall Pty Ltd.