Date calculations in multiple time zones

[lduperval]

Hi,

I`m trying to do date calculations in three types of time zones: local,
GMT and specified. The issue I am facing is that I need to be able to
specify a date in the proper time zone, and I`m having a heck of a time
doing so.

I have created a form where I use drop downs do specify year, month,
date, hour, minute and seconds. When the form is loaded, the dropdowns
have to display the proper values for the current time zone type. This
code works (the one that syncs the dropdowns with a given time).

When I submit my form, the data is sent to a Java back end. The back
end will take the year, month, date, hour, minute, seconds values and
generate the proper date, using the java.util.Calendar object. That
part works fine also.

The Javascript date calculations, though, doesn't work as well. In
essence, this is what I want. Let's say it is 4:00M EDT and I am in
the EDT time zone. So far, so good.

If I go to my form, select "Local" as my time zone, I want my form to
show up with 16, 0, and 0 preselected in my dropdown lists.

If I choose "GMT", I want 20, 0, and 0 to be selected.

If I select "PST", I want 13, 0, and 0 to be selected.

On my form, I have some values that I can change that will do certain
interval calculations which will be posted to my Java backend. When I
do these calculations, they have to be done according to the currently
selected time zone or it will not give the proper values to the
backend.

The problem I am seeing is that all my date calculations are done using
my local time. What approach can I use to make the calculations match
the currently selected time zone?

Thanks for all help,

L

 

[lduperval]

Before the page is displayed, the user must select a time zone to use.
There are three choices: GMT, local, and "pick one".

So once the page is shown, all the date and time values displayed must
match the selected timezone. A same user can display the page using a
different time zone, but she has to reload the page. IOW, you can't
select to display in GMT, load the page then, while viewing the page,
ask to display in local time. If you want to change the page view from
GMT to Local time, you have to first change the time zone to use, then
reload the page.

Is that any clearer?

L

 

[lduperval]

In the backend, that's what happens. Java has pretty good Timezone
handling
capabilities. My problem is getting the Javascript display to do what
the Java
backend does: dissociate the date display from the actual time value.

In Javascript, there are two date formats: local time and UTC time. It
looks to
me like I can't deal with dates in an arbitrary time zone. It looks to
me like
dealing with arbitrary time zones requires some outside intervention
from me,
to tell Javascript how to deal with that issue.

My code looks like this:

/**
* I have a percentage box. When the user modifies that value, dates
and
* times are modified in the form.
*/
function updateDatesAndTimes(objForm, objPercent) {

pct = objPercent.value;
if (pct>100) {
pct = 100;
objPercent.value=100;
} else if (pct < 0) {
pct = 0;
objPercent.value=0;
}

// Update distance
objForm.actv_distance.value=origDistance * pct / 100;

objForm.actv_distance2.value=origDistance-objForm.actv_distance.value;
objForm.actv_odo_value.value=origOdoValue -
objForm.actv_distance2.value;

// Update dates and times
==> // actvBeginTime contains a date in milliseconds value
updateTime = new Date();
updateTime.setTime(actvBeginTime + (actvElapsedTime * pct /100));
==> // Here, the date and time values are displayed for the user. This
is where my problem
// occurs because I am not displaying in the correct time zone.
form.displayDate2.value = formatDateAsDate(updateTime,
objForm.beginDate2);
form.beginTime2.value = formatDateAsTime(updateTime);

// update duration times
form.legDuration.value = formatTime(actvElapsedTime * pct /100);
form.legDuration2.value = formatTime(actvElapsedTime -
(actvElapsedTime * pct /100));

}


/**
* Return the time of day for a given date in HH:mm::ss format.
* The value must change according to the time zone in effect. The time
* zone is not necessarily the client time zone nor GMT/UTC.
*/
function formatDateAsTime(time) {
var hour = time.getHours();
var minute = time.getMinutes();
var second = time.getSeconds();
var temp = ((hour < 10) ? "0" : "") + hour;
temp += ((minute < 10) ? ":0" : ":") + minute;
temp += ((second < 10) ? ":0" : ":") + second;
return temp;
}

L

 

[lduperval]

My code looks like this:

Ahh! Someon just gave me an idea: change the Locale for my request to
reflect the time zone I want to use. If I do that, I can use local
timezone all the time and the data display and calculations will be
correct.

I'll try that.

L

 

[lduperval]

which will lonly work if the clients machine is set up the same way...

Yep... I'm realising that the locale isn't enough. What I'm leaning
towards is to add the timezone offset in the request and use that on my
page to display it correctly. IOW, in the function that formats dates
to display, I'll pad the time value witht the timezone offset value.

From there, I'll be able to affect only the display, while all the

calculations remain correct.

I'm working on it from that angle.

L

 

[Dr John Stockton]

JRS: In article <[email protected]>,
dated Wed, 14 Sep 2005 13:40:22, seen in (e-mail address removed) posted :

I`m trying to do date calculations in three types of time zones: local,
GMT and specified. The issue I am facing is that I need to be able to
specify a date in the proper time zone, and I`m having a heck of a time
doing so.

Please explain why reading the newsgroup FAQ has not helped you.

The Javascript date calculations, though, doesn't work as well. In
essence, this is what I want. Let's say it is 4:00M EDT and I am in
the EDT time zone. So far, so good.

EDT is not a time zone. Time zones are geographical areas, which exist
the whole year round.

TLAs (other than GMT and UTC) are not adequate to describe either zones
or offsets from UTC; EST has at least two meanings and BST at least
three.

 

[Dr John Stockton]

JRS: In article <[email protected]>
, dated Thu, 15 Sep 2005 06:57:28, seen in

Ahh! Someon just gave me an idea: change the Locale for my request to
reflect the time zone I want to use. If I do that, I can use local
timezone all the time and the data display and calculations will be
correct.

That's a really stupid idea if running in a system (such as Windows)
where many processes run at once. Any other time-dependent process may
get confused, especially appointments software.

It might be safe enough in a intranet on which all machines were DOS.

Read the Newsgroup FAQ; see below.

 

[lduperval]

Please explain why reading the newsgroup FAQ has not helped you.

Well, for what I'm trying to do, I din't see anything that addresses
the issue. There's a lot of theory on date calculations and warnings.
But in order to do what I want to do, there isn't anything.

In my case, the only thing that seems to work correctly is to manage
everything using seconds instead of actual Date instances. I then do
the manual formatting of the data to display it correctly on the site.

In my case, displaying the TLA is not important. What is important are
the hours/minutes/seconds adjusted correctly, "correctly" being a
different beast than common usage seems to dictacte.

L

 

[Dr John Stockton]

JRS: In article <[email protected]>
, dated Fri, 16 Sep 2005 12:19:28, seen in

Well, for what I'm trying to do, I din't see anything that addresses
the issue. There's a lot of theory on date calculations and warnings.
But in order to do what I want to do, there isn't anything.

Well, you may be right; I have not understood just what it is that you
want to do. What you appear to say that you want to do is easy enough,
provided that the meanings of the TLAs are known.

In my case, the only thing that seems to work correctly is to manage
everything using seconds instead of actual Date instances.

Administrative work, such as displaying a calendar of whole days, can
with care be done using the localised Date methods. But for anything
dealing with real time, one should use UTC methods.

I then do
the manual formatting of the data to display it correctly on the site.

If one is writing for the WWW, as is the default assumption here, one
will always need manual formatting, since one cannot trust either that
the localisation is set to suit the user or that the browser writer uses
it correctly. If one is writing for the USA only, or for an intranet,
manual formatting may be unnecessary.

In my case, displaying the TLA is not important. What is important are
the hours/minutes/seconds adjusted correctly, "correctly" being a
different beast than common usage seems to dictacte.

To comment meaningfully on that, one would need to know both what you
consider to be correct and what you consider common usage dictates. It
may well be that neither is actually "right".