Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > getTime, setTime, recent change in daylight savings

Reply
Thread Tools

getTime, setTime, recent change in daylight savings

 
 
Zamdrist
Guest
Posts: n/a
 
      04-06-2009
I'm looking at an application written by a third party, its not my
code. While I'm a programmer type, I'm not terribly versed in the
details of Javacript.

Our problems lies in that during the recent daylight savings change,
we've had a user, who resides in the Mountain timezone. The software,
a web application was showing a timer with the the wrong start time,
one hour wrong. Both the server and his machine said the correct time,
that is Windows said the correct time.

I think I've tracked down the code from the application that
determines the time. Can someone tell me if this code is correct, and
if its possible determine if it could be the culprit?

var date = new Date();
date.setTime(date.getTime() + 3650*24*60*60*1000);

I know that getTime returns the number of milliseconds from 1/1/1970,
so supposedly the addition of (3650*24*60*60*1000) brings the value of
getTime to a current time...?

Ideas? Thanks
 
Reply With Quote
 
 
 
 
Thomas Allen
Guest
Posts: n/a
 
      04-06-2009
On Apr 6, 2:47*pm, Zamdrist <(E-Mail Removed)> wrote:
> I'm looking at an application written by a third party, its not my
> code. While I'm a programmer type, I'm not terribly versed in the
> details of Javacript.
>
> Our *problems lies in that during the recent daylight savings change,
> we've had a user, who resides in the Mountain timezone. The software,
> a web application was showing a timer with the the wrong start time,
> one hour wrong. Both the server and his machine said the correct time,
> that is Windows said the correct time.
>
> I think I've tracked down the code from the application that
> determines the time. Can someone tell me if this code is correct, and
> if its possible determine if it could be the culprit?
>
> var date = new Date();
> date.setTime(date.getTime() + 3650*24*60*60*1000);
>
> I know that getTime returns the number of milliseconds from 1/1/1970,
> so supposedly the addition of (3650*24*60*60*1000) brings the value of
> getTime to a current time...?
>
> Ideas? Thanks


Well, the added milliseconds part is about ten years (3650 * ms in a
day). I have no idea why that code would be there. A new Date object
is current by default, so no need to "bring it up to date" as you
mentioned.

Thomas
 
Reply With Quote
 
 
 
 
Zamdrist
Guest
Posts: n/a
 
      04-06-2009
On Apr 6, 1:58*pm, Thomas Allen <(E-Mail Removed)> wrote:
> On Apr 6, 2:47*pm, Zamdrist <(E-Mail Removed)> wrote:
>
>
>
> > I'm looking at an application written by a third party, its not my
> > code. While I'm a programmer type, I'm not terribly versed in the
> > details of Javacript.

>
> > Our *problems lies in that during the recent daylight savings change,
> > we've had a user, who resides in the Mountain timezone. The software,
> > a web application was showing a timer with the the wrong start time,
> > one hour wrong. Both the server and his machine said the correct time,
> > that is Windows said the correct time.

>
> > I think I've tracked down the code from the application that
> > determines the time. Can someone tell me if this code is correct, and
> > if its possible determine if it could be the culprit?

>
> > var date = new Date();
> > date.setTime(date.getTime() + 3650*24*60*60*1000);

>
> > I know that getTime returns the number of milliseconds from 1/1/1970,
> > so supposedly the addition of (3650*24*60*60*1000) brings the value of
> > getTime to a current time...?

>
> > Ideas? Thanks

>
> Well, the added milliseconds part is about ten years (3650 * ms in a
> day). I have no idea why that code would be there. A new Date object
> is current by default, so no need to "bring it up to date" as you
> mentioned.
>
> Thomas


What's interesting, using Firefox's javacript code window I added
window.alert(date);

And sure enough its one hour off (early). It also says GMT -0600 (CST)

Is it just expressing that the current time CST is 6 hours prior to
GMT?
 
Reply With Quote
 
Zamdrist
Guest
Posts: n/a
 
      04-06-2009
I think because the code runs server side (CST) the calculation is
there to account for the user being in a different time zone? Its the
only think that makes sense to me.
 
Reply With Quote
 
Thomas Allen
Guest
Posts: n/a
 
      04-06-2009
On Apr 6, 3:47*pm, Zamdrist <(E-Mail Removed)> wrote:
> I think because the code runs server side (CST) the calculation is
> there to account for the user being in a different time zone? Its the
> only think that makes sense to me.


Date checks the local time, not a server. I don't know enough about
the implementation to speculate as to why the time zones may not
match, and I've never experienced this problem before. It sounds like
something OS-level.

Thomas
 
Reply With Quote
 
Evertjan.
Guest
Posts: n/a
 
      04-06-2009
Thomas Allen wrote on 06 apr 2009 in comp.lang.javascript:

> On Apr 6, 3:47’pm, Zamdrist <(E-Mail Removed)> wrote:
>> I think because the code runs server side (CST) the calculation is
>> there to account for the user being in a different time zone? Its the
>> only think that makes sense to me.

>
> Date checks the local time, not a server.


It can be server local or client local
depending on where the Javascript executes.

=======================================
Server time was:
<%
response.write(new Date());
%>

<br>
and client time was:

<script type='text/javascript'>
document.write(new Date());
</script>

<br>
when this pege was loaded.
=======================================

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
 
Reply With Quote
 
Zamdrist
Guest
Posts: n/a
 
      04-06-2009
On Apr 6, 3:00*pm, "Evertjan." <(E-Mail Removed)> wrote:
> Thomas Allen wrote on 06 apr 2009 in comp.lang.javascript:
>
> > On Apr 6, 3:47’pm, Zamdrist <(E-Mail Removed)> wrote:
> >> I think because the code runs server side (CST) the calculation is
> >> there to account for the user being in a different time zone? Its the
> >> only think that makes sense to me.

>
> > Date checks the local time, not a server.

>
> It can be server local or client local
> depending on where the Javascript executes.
>
> =======================================
> Server time was:
> <%
> response.write(new Date());
> %>
>
> <br>
> and client time was:
>
> <script type='text/javascript'>
> document.write(new Date());
> </script>
>
> <br>
> when this pege was loaded.
> =======================================
>
> --
> Evertjan.
> The Netherlands.
> (Please change the x'es to dots in my emailaddress)


That's what I figured, all depends on where the code executes. And so
far as I can tell, it executes on the server.

If its an OS-level issue with the client or server, I don't know how
when the times on both the server and client have always shown the
correct time. Its only the web application, and I'm presuming the code
I posted that calculates the wrong time.

Try it:

var date = new Date();
date.setTime(date.getTime() + 3650*24*60*60*1000);
window.alert(date);
 
Reply With Quote
 
Thomas Allen
Guest
Posts: n/a
 
      04-06-2009
On Apr 6, 4:18*pm, Zamdrist <(E-Mail Removed)> wrote:
> On Apr 6, 3:00*pm, "Evertjan." <(E-Mail Removed)> wrote:
>
>
>
> > Thomas Allen wrote on 06 apr 2009 in comp.lang.javascript:

>
> > > On Apr 6, 3:47’pm, Zamdrist <(E-Mail Removed)> wrote:
> > >> I think because the code runs server side (CST) the calculation is
> > >> there to account for the user being in a different time zone? Its the
> > >> only think that makes sense to me.

>
> > > Date checks the local time, not a server.

>
> > It can be server local or client local
> > depending on where the Javascript executes.

>
> > =======================================
> > Server time was:
> > <%
> > response.write(new Date());
> > %>

>
> > <br>
> > and client time was:

>
> > <script type='text/javascript'>
> > document.write(new Date());
> > </script>

>
> > <br>
> > when this pege was loaded.
> > =======================================

>
> > --
> > Evertjan.
> > The Netherlands.
> > (Please change the x'es to dots in my emailaddress)

>
> That's what I figured, all depends on where the code executes. And so
> far as I can tell, it executes on the server.
>
> If its an OS-level issue with the client or server, I don't know how
> when the times on both the server and client have always shown the
> correct time. Its only the web application, and I'm presuming the code
> I posted that calculates the wrong time.
>
> Try it:
>
> var date = new Date();
> date.setTime(date.getTime() + 3650*24*60*60*1000);
> window.alert(date);


What you have there posts the wrong time, about ten years ahead.
Hours:Minutes:Seconds are correct however.

Thomas
 
Reply With Quote
 
Zamdrist
Guest
Posts: n/a
 
      04-06-2009
On Apr 6, 3:22*pm, Thomas Allen <(E-Mail Removed)> wrote:
> On Apr 6, 4:18*pm, Zamdrist <(E-Mail Removed)> wrote:
>
>
>
> > On Apr 6, 3:00*pm, "Evertjan." <(E-Mail Removed)> wrote:

>
> > > Thomas Allen wrote on 06 apr 2009 in comp.lang.javascript:

>
> > > > On Apr 6, 3:47’pm, Zamdrist <(E-Mail Removed)> wrote:
> > > >> I think because the code runs server side (CST) the calculation is
> > > >> there to account for the user being in a different time zone? Its the
> > > >> only think that makes sense to me.

>
> > > > Date checks the local time, not a server.

>
> > > It can be server local or client local
> > > depending on where the Javascript executes.

>
> > > =======================================
> > > Server time was:
> > > <%
> > > response.write(new Date());
> > > %>

>
> > > <br>
> > > and client time was:

>
> > > <script type='text/javascript'>
> > > document.write(new Date());
> > > </script>

>
> > > <br>
> > > when this pege was loaded.
> > > =======================================

>
> > > --
> > > Evertjan.
> > > The Netherlands.
> > > (Please change the x'es to dots in my emailaddress)

>
> > That's what I figured, all depends on where the code executes. And so
> > far as I can tell, it executes on the server.

>
> > If its an OS-level issue with the client or server, I don't know how
> > when the times on both the server and client have always shown the
> > correct time. Its only the web application, and I'm presuming the code
> > I posted that calculates the wrong time.

>
> > Try it:

>
> > var date = new Date();
> > date.setTime(date.getTime() + 3650*24*60*60*1000);
> > window.alert(date);

>
> What you have there posts the wrong time, about ten years ahead.
> Hours:Minutes:Seconds are correct however.
>
> Thomas


Yeah, its goofy. Like I said, I didn't write it. Someone who makes a
rude amount of money more than I do, did.
 
Reply With Quote
 
RobG
Guest
Posts: n/a
 
      04-06-2009
On Apr 7, 5:04 am, Zamdrist <(E-Mail Removed)> wrote:
> On Apr 6, 1:58 pm, Thomas Allen <(E-Mail Removed)> wrote:
>
>
>
> > On Apr 6, 2:47 pm, Zamdrist <(E-Mail Removed)> wrote:

>
> > > I'm looking at an application written by a third party, its not my
> > > code. While I'm a programmer type, I'm not terribly versed in the
> > > details of Javacript.

>
> > > Our problems lies in that during the recent daylight savings change,
> > > we've had a user, who resides in the Mountain timezone. The software,
> > > a web application was showing a timer with the the wrong start time,
> > > one hour wrong. Both the server and his machine said the correct time,
> > > that is Windows said the correct time.

>
> > > I think I've tracked down the code from the application that
> > > determines the time. Can someone tell me if this code is correct, and
> > > if its possible determine if it could be the culprit?

>
> > > var date = new Date();
> > > date.setTime(date.getTime() + 3650*24*60*60*1000);


That is very strange code. It adds about 10 years to the date object
created by new Date, but does not account for for leap years. Since
it is roughly (not exactly) a whole number of years, daylight saving
will affect the calculation for a few days per year.

If you want to find out how many seconds there are between now and
some date in the future, use the setYear, setMonth and setDate methods
of a date object, then subtract the two times, e.g.

var now = new Date();
var tenYearsHence = new Date(+now);
tenYearsHence.setYear(now.getFullYear() + 10);

alert(
'Now: ' + now
+ '\nTen years hence: ' + tenYearsHence
+ '\nSeconds between: ' + (tenYearsHence - now)/1000
);


Of course using local calculations for dates is always problemtatic as
you don't know whether the system's clock is correctly set or that the
user knows what it is (it may not be their system, nor might they have
control over the date and time settings).


> > > I know that getTime returns the number of milliseconds from 1/1/1970,
> > > so supposedly the addition of (3650*24*60*60*1000) brings the value of
> > > getTime to a current time...?


No. It gives a date about 1 to 3 days short of 10 years in the
future. Depending on when the date is calculated, there might be one,
two or three leap years in between that aren't accounted for and it
might therefore also not account for a daylight saving time change, so
it might be out by an hour one way or the other occassionally.


> > > Ideas? Thanks

>
> > Well, the added milliseconds part is about ten years (3650 * ms in a
> > day). I have no idea why that code would be there. A new Date object
> > is current by default, so no need to "bring it up to date" as you
> > mentioned.


It is current for the system settings, which may not be correct.


> What's interesting, using Firefox's javacript code window I added
> window.alert(date);


Presumably you did:

alert(new Date());

> And sure enough its one hour off (early).


That means you have a setting somwhere that is inconsistent with what
you think the local time is.


> It also says GMT -0600 (CST)
>
> Is it just expressing that the current time CST is 6 hours prior to
> GMT?


The opposite: the time is 6 hours behind UTC (GMT is more or less
deprecated, although still commonly used).

<URL: http://en.wikipedia.org/wiki/GMT >

You can use date.getTimezoneOffset() to see the offset in minutes (for
UTC -0600 it should say 360, my timezone is UTC +1000 so I get -600).
The timezone offset is added to the local time to get UTC.

When dealing with time, it is best to do everything in UTC and convert
to local time only for the sake of display. It may also be prudent to
display the result of new Date() so the user can check if it is
correct (and hence infer whether calculations based on it are likely
to be correct).


--
Rob
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
NZ Daylight Savings change impact Jim.Seedlenissip@gmail.com NZ Computing 19 09-03-2007 04:46 AM
Daylight Savings Time Change Phil Computer Support 4 02-21-2007 12:46 AM
Daylight Savings time configuration Andrew Barnes Cisco 2 03-24-2006 06:45 PM
Help with DateTime and TimeZones / DayLight savings time Ryan Ternier ASP .Net 1 10-14-2005 05:20 PM
Daylight savings problem Svante Nicholas Arvedahl Java 9 10-24-2003 08:19 AM



Advertisments