Client Time Zone

Thank you for mentioning about the Date Object. Perhaps that is all I need. I know all about it, though. See http://home.socal.rr.com/samhobbs/JScriptDateMethods.html for an example of something simple I created to play with it.

I guess the reason I did not consider Date.getTimezoneOffset() is because of daylight savings time. It makes things more complicated than I would have expected. In the Windows registry the time zone data says that daylight savings time applies to GMT, and that made things complicated for me when I wrote a program to use that data. I suppose that using the current time zone offset for each client for each session would negate the necessity of figuring out the affect of daylight savings time but for some reason I would prefer to have the actual time zone rather than a time zone offset.

I also have a lot of links to time zone material at http://home.socal.rr.com/samhobbs/TimeStuff.html

I have not yet looked at the sites you gave me, nettrom, but I will. For the moment it is late in the day for me.

My .2$ worth: IE mac has a REALLY funny timeZoneOffset if the user has NOT set his timezone on the mac itself.
You might want to test that it s a valid amount

Michel

This one parses string representation of date search for IEEE standard  
GMT+XXXX or UTC+XXXX pattern
(as this usually don't include DLST)
and parse it. If pattern not found
than getTimezoneOffset() will be used.

<script>
  var d=new Date()
  var s = d.toString();

  // on case we wouldn't able to parse from string
  var offset=d.getTimezoneOffset();

  inx = s.indexOf("GMT");

  if(inx==-1){
    inx=s.indexOf("UTC");    
  }

  if(inx>=0 && s.length >=8){ s=s.substring(inx+3)
        s=s.substring(0,5);
        // to make offset the same as getTimezoneOffset return
        // we need to invert sign;
        sig=-1;
        if(s.charAt(0)=='+') sig=-1;
        var min=parseInt(s.substring(3));        
        var hour=parseInt(s.substring(1,3));
        offset = sig* hour*60 + min;
  }
  document.writeln(offset);
 
</script>

I apologize for taking so much time to respond but I wanted to be as accurate as possible in my response.

I think that kollegov's answer assumes some things that are not accurate. In particular, it appears that most systems in the United States probably do not use the GMT+XXXX or UTC+XXXX formats. I added the following line at the bottom of the script:

document.writeln(" | " + inx + " | " + d.toString());

and for just now I got:

480 | -1 | Tue Mar 28 14:23:42 PST 2000

The 480 is from the:

document.writeln(offset);

that is at the bottom of the script as shown above. So the "-1" shows that neither GMT nor UTC were found. Which means that for many, probably most, uses, the effect will be that getTimezoneOffset() will be used, and I think that it would be best to just use getTimezoneOffset() by itself in all situations.

Still, there might be value in the extra processing, but that solution still does not provide a time zone. Technically speaking, an offset is not a time zone. If someone knows of an algorithm that can reliably convert a time zone offset to a time zone, then that would be good, but if it is not easy to do reliably, then that indicates that an offset is not a time zone.

The main thing that required time for me to respond is that I wanted to find documentation for the syntax of the string produced by the toString method of the Date object. I was looking for specifications that are detailed enough to write parsing logic to get the timezone from the string. I cannot find that documentation, so if someone knows where that documentation is, then that would help. I would like to have specifications rather than to use trial and error to determine the syntax.

I am usually the person answering questions instead of asking questions and it is more difficult to be the one asking questions because it is not easy to decide how to respond in situations like this.

I am sorry, kollegov, but I cannot use the processing you have offered. I am a programmer that is quite capable of writing logic such as that. I just need the documentation and/or information (if available) for the peice I am missing.

Thank you for trying to help.

I don't think there is any documentation found about the result of String(date), and my gut feeling is that the result is highly unreliable.  compare to document.lastModified (which is a string), I've seen 8 different formats, and I haven't even researched a lot.

as far as I'm concerned, if you want to do any sort of serious date-manipulation, you should stay away from anything called "String".  once you convert it to a string you'll probably have to live with several different formats of which parsing _will_ be difficult.

you mention daylight savings time, but is that really a serious problem?  as far as I know the date for conversion to/from DST is defined, and therefore can be used in the calculation.  but I'm not immensely experienced when it comes to date-manipulation.

so, in my opinion, you should stay with the Date object and getTimezoneOffset() and then work your way from there.  a list of the names of different time zones shouldn't be too hard to find, and dates for converting to/from daylight savings time should also be available somewhere.  the rest is all a matter of mathematics.

Can you insert SSI on your server?
If yes, than everything simple as an egg..If no see alternatives at the end..

//create server date from one told by server.

var serverDate=new Date('<!--#echo VAR="DATE_GMT"-->');

//or use any other way to pass valid
//GMT server time string to JavaScript so it will be able to parse it

//create client current date
var clientDate=new Date();

//calculate error (as both dates are GMT in millisec)
var clientError = serverDate.getTime() - clientDate.getTime();

clientOffset = Date.getTimezoneOffset() + Math.floor(clientError/1000/60/15)*15

As I don't ever seen timezones with less than 15 minutes step than /15 than floor and *15 will find best approximation within 15 minutes nearest
one.

Error can be in case of slow connection, but hardly it will be over 7.5 minutes to exeed floor ranges.

Something similar I did with Java Applet when I hadn't rights for SSI.
In this case my applet connected to server through socket (back to the same document) and parsed HTTP headers to get server date from there. The rest was the same...

I am sorry, kollegov, but this answer does not provide a timezone and does not provide any improvement compared to using getTimezoneOffset directly.

Can't agree with you, at least in second point :-)
You didn't got the idea...

As I told I tested this way with java applet. Nevertherlles have client
it's TZ correct or not, you would get correct client's offset relative to GMT.

Because on first step you calculate
client tzoffset !!!error!!!. and than you can account this error in your calculations.

Let's say you echoe GMT server date and than construct Date(fromServerCurrentDate) on client side. This is absolutely correct date
(at least if your server have correct date)  and you have with getTime() milliseconds elapsed since epohe start in terms of GMT.

Than you create Date() on client side and obtain with getTime() milliseconds from epoche start in terms of same GMT as client clock consider it is.

Substracting one from another you know now ERROR in millisec on client side.

This error includes both: DLST errors (if any) and TZ setting errors(if any)

Now you can calculate real clients' TZ offset relative to GMT in minutes.

Well, you don't have TZ name.. but you have correct offset. The problem is that the same offset can corresponds to different TZs...

I am sorry, kollegov, but I did not see your reply until now. Something must have happened to my system the day I received the email notification of it's arrival.

I am sorry that I do not understand "Nevertherlles have client
it's TZ correct or not", but yes, your function would at least return the offset from GMT.

Most of the rest of what you are saying I do not understand much of either, but as far as errors are concerned, the advantage of using getTimezoneOffset directly is that there is no need to be concerned about errors.

Your bottom line says "you have correct offset", which is no better than using getTimezoneOffset directly.

I need to emphasize that I did not ask for offset from GMT, I asked for time zone, and if an answer cannot provide a reliable conversion of offset to zone, then the implication is that there is not an easy and reliable conversion of offset to zone.

I need to emphasize that I did not ask for offset from GMT, I asked for time zone, and if an answer does not provide a reliable timezone, then the offset is insufficient.

The problem is that many clients all over the world DO NOT HAVE correct local TZ settings. For Example I personally  iz in Novosibirsk, Russia and for several years had not Novosibirsk TZ at all.(Only after I got TZeditor program I created correct one for myself)
Windows do not provide any TZ which was sutable (+6 +DLST) for me.
So in summer I used +7 without DLST
and in winter I used +6 without DLST.

In many cases Win users just shift clock 1 hour for DLST and back without taking care about changing TZoffset.

Many users are even Never take care about thier TZ. they have clock showing local time correctly, but may have ANY timezone.

Even More! Many standard windows TZs have wrong DLSTs which makes them useless..

Generaly, there is no way to get TZ on client side and be sure it correct.

More or less this can be correct for US
and Europe, but not for the rest of world.

That's what I'm tryed to explain in
previous posts..

What for do you need client TZ name if
can't be sure it iz correct ????
That's what I tryed to explain.

If this just to display to client his TZ than you can do the following in Netscape:

<script>
alert(java.util.TimeZone.getDefault().getID());
</script>

MIE unfortunatly do not allow to
call java directly this way, so you would need to implement simple applet

With netscape.javascript.*
package you can call javascript function from applet. So when applet loads it call JS function to pass value to JavaScript

Something like this:

import java.applet.*;
import netscape.javascript.*;

public class VMaxTZget extends Applet{

public void init(){
  String tz=java.util.TimeZone.getDefault().getID();
  evaluatejs("setTZ('"+tz+"')");
 }

 void evaluatejs(String cmd){
   ... omited ...
 }

}
----------

HTML will be like this:
-----------
<HTML>
<script>
function setTZ(s){
   alert(s);
}
</script>
<APPLET CODE=VMaxTZget.class WIDTH=1 HEIGHT=1 MAYSCRIPT>
</APPLET>
</HTML>

I can e-mail compiled class file to you..contact me virtual_max@geocities.com

Applet solution was tested with
NN4.61, MIE5 Win95

--------------
Virtual_Max

P.S. Adding more points will be greatly appreciated.

Certainly I am aware of the problem of missing or inaccurate timezones etc. Those are separate problems with separate solutions. I intend to solve those problems with different solutions.

My request is for "the client's time zone using JavaScript". My intent was to determine if it is worthwhile for me to use another language. If JavaScript can satisfy my requirements, then I want to use it, but if it will not, then I assume that it will be easy enough to find the documentation for the other language(s) describing how I can get the timezone.

Well, and what about java applet solution I suggested ?

Do you need working example?
I can't post .class file here, but I can e-mail it to you.