UTC date and time to local

[maflatoun]

Hi,

I have the following function to convert UTC time to Local time. It
works perfect for GMT- (Minus) time zones however it provides incorrect
results for GMT+(Plus) time zones?

// Format to local time from UTC
function formatToLocalTimeDate(inDate) {
var today = new Date();
var inDateMod = new Date(inDate);
offSet = today.getTimezoneOffset();
if(offSet < 0) {
inDateMod.setMinutes(inDateMod.getMinutes()+offSet);
} else {
inDateMod.setMinutes(inDateMod.getMinutes()-offSet);
}
return inDateMod;
}

Can anyone help with this? Or does anyone have a code that would do
this for me?
Thanks
Maz.

 

[Hal Rosser]

Hi,

I have the following function to convert UTC time to Local time. It
works perfect for GMT- (Minus) time zones however it provides incorrect
results for GMT+(Plus) time zones?

// Format to local time from UTC
function formatToLocalTimeDate(inDate) {
var today = new Date();
var inDateMod = new Date(inDate);
offSet = today.getTimezoneOffset();
if(offSet < 0) {
inDateMod.setMinutes(inDateMod.getMinutes()+offSet);
} else {
inDateMod.setMinutes(inDateMod.getMinutes()-offSet);
}
return inDateMod;
}

Can anyone help with this? Or does anyone have a code that would do
this for me?
Thanks
Maz.

Take a look at the
dateObj.setUTCHours(hh,mm) method -
If you set those, then the (local) time will be set automagically.
At least it does in Firefox, where I just tested it.
http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Global_Objects:Date#Methods
Hope this helps

 

[Thomas 'PointedEars' Lahn]

I have the following function to convert UTC time to Local time. It
works perfect for GMT- (Minus) time zones however it provides incorrect
results for GMT+(Plus) time zones?

// Format to local time from UTC
function formatToLocalTimeDate(inDate) {
var today = new Date();
var inDateMod = new Date(inDate);
offSet = today.getTimezoneOffset();
if(offSet < 0) {
inDateMod.setMinutes(inDateMod.getMinutes()+offSet);
} else {
inDateMod.setMinutes(inDateMod.getMinutes()-offSet);

Date.prototype.getMinutes() already returns the minutes in the
local time.

If you really wanted to convert from UTC to local time (which is
entirely redundant), you would need to retrieve the value with
Date.prototype.getUTCMinutes() instead.


PointedEars

 

[Dr John Stockton]

JRS: In article <[email protected]>
, dated Sat, 8 Apr 2006 22:00:21 remote, seen in
news:comp.lang.javascript, (e-mail address removed) posted :

I have the following function to convert UTC time to Local time. It
works perfect for GMT- (Minus) time zones however it provides incorrect
results for GMT+(Plus) time zones?

// Format to local time from UTC
function formatToLocalTimeDate(inDate) {
var today = new Date();
var inDateMod = new Date(inDate);

Inefficient, if inDate arrives as a Date Object : use
var inDateMod = new Date(+inDate);
to copy the value of a Date Object.

offSet = today.getTimezoneOffset();
if(offSet < 0) {
inDateMod.setMinutes(inDateMod.getMinutes()+offSet);
} else {
inDateMod.setMinutes(inDateMod.getMinutes()-offSet);
}
return inDateMod;
}

Can anyone help with this? Or does anyone have a code that would do
this for me?

Anyone who thinks it appropriate to add negative offsets and subtract
positive ones is not worth copying from, and should be advised to take
up knitting instead of computing.

Including the current offset in a non-current time seems unlikely to be
useful.

Be aware that crossing a Summer Time change with setMinutes() may not
give the expected result.

The only reason I can at present see for doing something like that would
be when dealing with someone else's local time. But as it does not do
what you claim, and neither makes sense, it's hard to see what you do
need.

inDateMod = new Date(+inDate +- 6e4*new Date().getTimezoneOffset())

should do much what your code's programmer was thinking of, but more
efficiently.

Read the newsgroup FAQ; see below.

 

[Hal Rosser]

Take a look at the
dateObj.setUTCHours(hh,mm) method -
If you set those, then the (local) time will be set automagically.
At least it does in Firefox, where I just tested it.
http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Global_Objects:Date#Methods
Hope this helps

Try this -( assumes the time zone is set correctly in the machine using the
code)
// Format to local time from UTC
function formatToLocalTimeDate(inDate) {
var inDateMod = new Date(inDate);
inDateMod.setUTCHours( inDate.getHours()) ; //**
return inDateMod;
}// ** (the minutes and seconds were set when created from inDate)

 

[Evertjan.]

Dr John Stockton wrote on 09 apr 2006 in comp.lang.javascript:

inDateMod = new Date(+inDate +- 6e4*new Date().getTimezoneOffset())

should do much what your code's programmer was thinking of, but more
efficiently.

Why the +- operator?

 

[Dr John Stockton]

JRS: In article <[email protected]>, dated Mon, 10
Apr 2006 08:27:23 remote, seen in Evertjan.

Dr John Stockton wrote on 09 apr 2006 in comp.lang.javascript:


Why the +- operator?

Because the character given by ± in HTML is unsuitable for plain-
text News; as the original requirement does not make much direct sense,
I didn't trouble to decide whether + or - might be better.

 

[Dr John Stockton]

JRS: In article <[email protected]>, dated
Sun, 9 Apr 2006 19:32:44 remote, seen in Hal

Try this -( assumes the time zone is set correctly in the machine using the
code)
// Format to local time from UTC
function formatToLocalTimeDate(inDate) {
var inDateMod = new Date(inDate);
inDateMod.setUTCHours( inDate.getHours()) ; //**
return inDateMod;
}// ** (the minutes and seconds were set when created from inDate)

You are four hours behind Greenwich Mean Time at present, it seems.

If that code is executed at 7.30 p.m. local = 23:30 GMT, the fundamental
contents of inDateMod will be reduced by four hours.

If that code is executed at 8.30 p.m. local = 00:30 GMT, the fundamental
contents of inDateMod will be increased by twenty hours.

One of those might be useful; it seems unlikely that both will be.

Now consider your readers in Mumbai, if any there be. Their local time
is 5h 30m ahead of GMT, so there seems to be an additional effect
changing each half-hour when using your code. The same applies, for
half the year, to readers in Lord Howe Island.



It's obvious enough, as previously indicated, why the original code
gives a difference between localities on each side of GMT; but as what
the OP really needs is a mystery, one can offer little more.

The OP should read the newsgroup FAQ; see below.

 

[Hal Rosser]

JRS: In article <[email protected]>, dated
Sun, 9 Apr 2006 19:32:44 remote, seen in Hal



Now consider your readers in Mumbai, if any there be. Their local time
is 5h 30m ahead of GMT, so there seems to be an additional effect
changing each half-hour when using your code. The same applies, for
half the year, to readers in Lord Howe Island.



It's obvious enough, as previously indicated, why the original code
gives a difference between localities on each side of GMT; but as what
the OP really needs is a mystery, one can offer little more.

The OP should read the newsgroup FAQ; see below.

I hope the OP was not in Kathmandu, Kabul, or Rangoon or Darwin.
some with x-and-a-half or x-and-3-quarter hours difference from zulu time.

 

[Hal Rosser]

JRS: In article <[email protected]>, dated
Sun, 9 Apr 2006 19:32:44 remote, seen in Hal



You are four hours behind Greenwich Mean Time at present, it seems.

If that code is executed at 7.30 p.m. local = 23:30 GMT, the fundamental
contents of inDateMod will be reduced by four hours.

If that code is executed at 8.30 p.m. local = 00:30 GMT, the fundamental
contents of inDateMod will be increased by twenty hours.

One of those might be useful; it seems unlikely that both will be.

Now consider your readers in Mumbai, if any there be. Their local time
is 5h 30m ahead of GMT, so there seems to be an additional effect
changing each half-hour when using your code. The same applies, for
half the year, to readers in Lord Howe Island.



It's obvious enough, as previously indicated, why the original code
gives a difference between localities on each side of GMT; but as what
the OP really needs is a mystery, one can offer little more.

So - if the user's computer's time and time zone is set correctly,
AND if the user has a "GMT Time" passed to a function, which he want to
convert to his 'Local Time'
THEN all he needs to do is create a date object and use the various
"setUTCxxx" (where xxx is the date, hour, minute) methods. - then the
"toLocaleString" method would show the correct local date and time. Isn't
this correct?
*** but if the user is only concerned with the 'time', then setting the
UTCHour on the date would probably be ok - unless he was in cameroon or
such - or if he was in daylight-savings time, and the date/time he was
converting was referencing a date before the time change. ?? this subject
has worn me out. But I found out some time zones are X plus/minus half-hour
and some three-quarter-hours ...

 

[Dr John Stockton]

JRS: In article <bye%[email protected]>, dated Wed,
12 Apr 2006 17:49:11 remote, seen in Hal

So - if the user's computer's time and time zone is set correctly,

Not sufficient. Time Zone is a geographical construct; it changes only
by "political" decision, and not by change of season. It is also
necessary to have the Summer Time Change rules correctly set for the
date/time/location in question.

AND if the user has a "GMT Time" passed to a function, which he want to
convert to his 'Local Time'
THEN all he needs to do is create a date object and use the various
"setUTCxxx" (where xxx is the date, hour, minute) methods. - then the
"toLocaleString" method would show the correct local date and time. Isn't
this correct?

No. Method toLocaleString does not necessarily show the correct local
date and time. It is supposed to, but one cannot rely on the minions of
Mr Gates to get it right. My system, set for UK, outputs 04/13/2006
12:12:27 - but at least it's not the 12-h clock (the systems in the
Public Library appear to be set for US).

For date output to be reliably comprehensible world-wide, use a 4-digit
year and the month in letters (assuming English is understood); or use
YYYY/MM/DD or YYYY-MM-DD with hh:mm:ss, which is understood everywhere,
even in the USA. Generate that by localisation-independent code.

However, what you suggest is an inefficient way of setting a Date Object
to a specified UTC moment; use one of

D = new Date(Date.UTC(Y, M-1, D, h, m, s, ms))
D = new Date("YYYY/MM/DD hh:mm:ss GMT")
D = new Date("YYYY/MM/DD hh:mm:ss Z")

where the first is reliable and the others are probably safe.

*** but if the user is only concerned with the 'time', then setting the
UTCHour on the date would probably be ok - unless he was in cameroon or
Cameroon?

such - or if he was in daylight-savings time, and the date/time he was
converting was referencing a date before the time change. ?? this subject
has worn me out. But I found out some time zones are X plus/minus half-hour
and some three-quarter-hours ...

Indeed : there's a "half-hour" Time Zone in English-speaking[*] North
America.

But have you yet found out about LHI?

You are, rather slowly, catching up - but you seem not to have taken due
advantage of the indications provided about where more can be learned.

[*] Scottish-speaking may be more accurate?

 

[maflatoun]

Based on everyone's input (instead of knitting) I came up with the
following and tested it for + - and GMT time.

function getlocaleDate(inDate)
{
var curUTCDate = new Date(inDate);
// May cause problem in the future b/c of mm/dd/yy format
utcDate = (curUTCDate.getMonth()+1) + "/" + curUTCDate.getDate() +
"/" + curUTCDate.getFullYear();
utcHour = curUTCDate.getHours();
utcMinute = curUTCDate.getMinutes();

var currentDate = new Date(utcDate);

currentDate.setUTCHours(utcHour);
currentDate.setUTCMinutes(utcMinute);
return currentDate;
}

Anyone wants to test it? Might not be very efficient but it seems to be
working.

Maz.

 

[maflatoun]

So - if the user's computer's time and time zone is set correctly,
AND if the user has a "GMT Time" passed to a function, which he want to
convert to his 'Local Time'
THEN all he needs to do is create a date object and use the various
"setUTCxxx" (where xxx is the date, hour, minute) methods. - then the
"toLocaleString" method would show the correct local date and time. Isn't
this correct?
*** but if the user is only concerned with the 'time', then setting the
UTCHour on the date would probably be ok - unless he was in cameroon or
such - or if he was in daylight-savings time, and the date/time he was
converting was referencing a date before the time change. ?? this subject
has worn me out. But I found out some time zones are X plus/minus half-hour
and some three-quarter-hours ...

Based on everyone's input (instead of knitting) I came up with the
following and tested it for + - and GMT time.

function getlocaleDate(inDate)
{
var curUTCDate = new Date(inDate);
// May cause problem in the future b/c of mm/dd/yy format
utcDate = (curUTCDate.getMonth()+1) + "/" +
curUTCDate.getDate() +
"/" + curUTCDate.getFullYear();
utcHour = curUTCDate.getHours();
utcMinute = curUTCDate.getMinutes();


var currentDate = new Date(utcDate);


currentDate.setUTCHours(utcHour);
currentDate.setUTCMinutes(utcMinute);
return currentDate;
}


Anyone wants to test it? Might not be very efficient but it seems to be

working.


Maz.

 

[Dr John Stockton]

JRS: In article <[email protected]>
, dated Thu, 13 Apr 2006 09:10:26 remote, seen in

Based on everyone's input (instead of knitting) I came up with the
following and tested it for + - and GMT time.

Since you don't indicate exactly what it is supposed to do, it's not
easy to test it.

function getlocaleDate(inDate)
{
var curUTCDate = new Date(inDate);

Inefficient (if inDate is an Object), and may fail for years before 69.

Use var curUTCDate = new Date(+inDate);

// May cause problem in the future b/c of mm/dd/yy format

But no-one with any intelligence uses that format in data processing.

utcDate = (curUTCDate.getMonth()+1) + "/" + curUTCDate.getDate() +
"/" + curUTCDate.getFullYear();
Ditto.

utcHour = curUTCDate.getHours();
utcMinute = curUTCDate.getMinutes();

var currentDate = new Date(utcDate);

currentDate.setUTCHours(utcHour);
currentDate.setUTCMinutes(utcMinute);
return currentDate;
}

Anyone wants to test it? Might not be very efficient but it seems to be
working.

Setting a Date Object so that, read as a Civil Date/Time, it shows the
same numbers as a given UTC Date/Time, is an unreasonable thing to want
(and not always possible : 2006 April 2nd 02:30 AM did not exist in much
of NA, and 2006 October 29th 01:30 AM will occur twice).

One can code the I/O to/from a Date Object of Local Civil Date/Time and
of UTC Date/Time, just with standard Methods.

The sensible things that may also be needed are to convert, in each
direction, between a Date Object (which holds GMT milliseconds) and a
String or a set of Numbers representing the Civil Date/Time at a
location which is independent of that of the browser. Those who have
studied the newsgroup FAQ should be able to deal with those, both for
the general case (even LHI) and for specific cases such as NA-only.