It is quite easy to get your system's timezone, as set in the OS, through JavaScript on the browser. Type these in the location/url:
javascript:alert(new Date())
javascript:alert(new Date().getTimezoneOffset())
The first shows the current time in your timezone, usually with a timezone offset and name, like "GMT-400 (EDT)". If that's too much parsing and math, the second shows minutes behind UTC. So if JavaScript is enabled, the site can get this value and stuff it in a field that gets submitted in a form, or simply send this info back to the server at any time.
So in addition to using a proxy to foil IP geolocation, you also need to disable JavaScript, which might break the site to some degree.
(And there are currently 40 timezones in use, not 24 -- some start at 30 and 45 minutes past the hour from UTC, and a few in the Pacific overlap by a day.)
EDIT: in addition to the timezone, you can also get your locale through the Date and Number objects: the order and separator for year, month, and day; and the thousands and decimal separators. Some combinations of these might, in a few cases, provide country-accurate location (or even slightly better -- it would be interesting to see a matrix of all the combinations).
Even if you could simply stub out Date and Number, that would probably break some useful functionality. So the best approach would be to modify the object prototypes so that they lie and use an arbitrarily chosen timezone and locale. That would require a fair amount of work on Date though; there are several related methods. For example, to force GMT:
Date.prototype.toString = Date.prototype.toGMTString;
Date.prototype.getTimezoneOffset = function() {return 0;};
// and about 10 more
As @barlop suggests, it looks like you can use Privoxy filters to modify the pages before they get to your browser. Due to (1) the way search and replace works with Privoxy, (2) the requirements of the patch, and (3) the flexible nature of HTML: you would have to apply the patch at the beginning of both the <head>
and <body>
(and even that is not 100% coverage).
Windows Vista / 7 and later
Windows Server 2003 and later
With a little effort you can use forfiles
to get the last modified time of a specific file, seconds included:
REM "delims=" is required to avoid stripping AM/PM
for /f "delims=" %%i in ('"forfiles /m filename /c "cmd /c echo @ftime" "') do set modif_time=%%i
echo %modif_time%
Example output
7:33:54 AM
The value displayed is based on the local time of the computer and matches the time shown in the file properties dialog.
Usage help
http://technet.microsoft.com/en-us/library/cc753551.aspx
Windows XP
forfiles.exe
is not available out of the box, however you can manually get the required executable. It's an old version which is part of the Windows 2000 Resource Kit. The syntax is case-sensitive and slightly different, and so is the output:
for /f %%i in ('"forfiles.exe -mfilename -c"cmd /c echo @FTIME" "') do set modif_time=%%i
echo %modif_time%
Example output
153354
Here the time value is displayed in the UTC format and is not affected by changes in time zone or daylight saving time. In this example the file was last modified at 15:33:54 (UTC).
Note You can obtain the newer forfiles.exe
version by grabbing a copy of the file from any Windows 2003 Server installation or setup media.
Best Answer
The time zone is an artefact of conversion from "instants" to a human-readable date-and-time in some calendar.
Computers do not like human-readable formats (not as much as humans, at least), so they usually store instants in a zone-neutral format. For instance, in the NTFS file system, time stamps are stored in UTC.
Hence, the file time modification is stored properly as long as whoever modifies it knows the current time. If your Windows system displays "13:19" and believes to be in the GMT-5 time zone, then it infers that the current instant is "18:19" in UTC, and writes as much in the NTFS entrails. However, if the OS displays "13:19" but believes to be in the GMT+3 time zone, then the OS is off by eight hours, even if, for the human looking at the screen, things seem fine.
Another point is that the file modification time is a property of the storage system in which the file is stored, e.g. a file system. When a file is "sent", then that time does not necessarily travels with it. Some archive formats (e.g. Zip) embed the file modification time along with the file. This does not apply to a file sent "as is", attached to an email, will not come with a file modification time.