reptile7's JavaScript blog: Times of Our World, Part 3

Sunday, March 10, 2019

Times of Our World, Part 3
Blog Entry #395

With the World Clock -- Daylight Savings Time's San Francisco particulars now under our belt, here are some...

Brief notes on the rest of the locale code

One of these offsets is not like the others

The GMT offsets for the remaining locales are:

Denver: hour - 7			London: hour + 0			Bangkok: hour + 7
Memphis: hour - 6		Paris: hour + 1			Tokyo: hour + 9 
New York: hour - 5		Moscow: hour + 3		Sydney: hour + 11

All are OK for standard time except the one for Sydney, whose standard-time GMT offset is actually hour + 10. Not all of Australia observes daylight saving time but New South Wales does, and we can make use of the hour + 11 offset if we want to, depending on the details of the standard time ↔ daylight saving time function we use for Sydney (vide infra).

When I'm twenty-four

Suppose we're in San Francisco and it's a Sunday in January and it's 3 p.m. (sf_hour = 15), for which the par_hour in Paris

var par_hour = hour + 1;

is 24. The Paris day and time display should read

Monday
12:00 a.m.

but in practice it reads

Sunday
12:00 p.m.

A miscoded

if (par_hour > 24) {

    par_hour -= 24;

    par_week += 1; }

conditional employs a >24 comparison to flag the p.m./a.m. boundary when it should use a >23 comparison to do so;
because the par_hour is not greater than 24,
it is not initially dropped to 0 by the -= 24 subtraction and therefore the par_ampm is toggled to p.m.

if (par_hour > 11) { par_ampm = " p.m."; }

and the par_week is not moved forward a day calendar-wise.
The London, Moscow, Bangkok, Tokyo, and Sydney code units all contain such a conditional although it doesn't cause a problem for those locales in this case because
the London lon_hour (23) is below the 24 threshold whereas
the Moscow mos_hour (26), Bangkok ban_hour (30), Tokyo tok_hour (32), and Sydney syd_hour (34) are all pushed above the 24 threshold by their GMT offsets.
The >24 comparison does cause a problem for those locales when their own *_hours are 24, however, so we of course need to change all those >24s to >23s.

Code consolidation

Upon arraying the dstclock clock's table cells

<table id="worldclockTable" border="1"> ...One row or three, the command below gets/arrays all 10 <td>s... </table>



var localeTds = document.getElementById("worldclockTable").getElementsByTagName("td");

and its GMT offsets

var gmtoffsetsArray = [-8, -7, -6, -5, 0, 1, 3, 7, 9, 10];

and upon generalizing the *_hour, *_week, and *_ampm variables

var locale_hour, locale_week, locale_ampm;

we can merge the San Francisco → Sydney code commands in both the dstclock head and body into a single statement block and automate their execution.

for (var i = 0; i < localeTds.length; i++) {

    locale_hour = hour + gmtoffsetsArray[i];

    locale_week = week;

    ...

You may have noticed that there are no functions in the dstclock code. I first consolidated the San Francisco → Sydney code units via a getLocaleDayTime(gmtoffset, td_index) { ... } function before recognizing that a top-level for loop could give us what we want in a simpler way.

If we recast the weekly day Array as

var weekly = ["Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday"]; // Per getDay( )'s indexing

then we can generalize the p.m./a.m. boundary code with

// For San Francisco, Denver, Memphis, and New York

if (locale_hour < 0) {

    locale_hour += 24;

    locale_week = ! locale_week ? 6 : locale_week - 1; }

// For London, Paris, Moscow, Bangkok, Tokyo, and Sydney

if (locale_hour > 23) {

    locale_hour -= 24;

    locale_week = locale_week == 6 ? 0 : locale_week + 1; }

// The ?: conditional operator is documented here.

With GMT-pegged locale_hours in hand we determine the locales' a.m./p.m. designations

locale_ampm = locale_hour > 11 ? " p.m." : " a.m.";

and then move the 13-23 and 0 locale_hours to the 12-hour scale

if (locale_hour > 12) locale_hour -= 12;

if (locale_hour == 0) locale_hour = 12;

and finally assemble the day and time displays and append them to the San Francisco → Sydney locale identifiers.

localeTds[i].innerHTML += weekly[locale_week] + "<br>" + locale_hour + ":" + min + locale_ampm; } // End of loop

Speaking of those locale identifiers, could we array them and loop them into, say, font-weight:bold;-ed <span>s? Why, yes, we could do that too.

Stuart did not have a cross-browser/platform way to array the table cells at his disposal - without getting into the details, IE 4 for Windows users could have done so via the document.all mechanism but Netscape/Mac users would have been out of luck - although he could have
loaded the locale displays into text inputs (as was typically done with such scripts back in the day) and
automated the loading action via the Form object's elements property.
Separately writing the displays as #PCDATA/<br> content to the page did at least give him the option of styling them in various ways (e.g., color them with the font element, render them in a monospace font via the tt element) although he chose not to do that.

We've got one last issue to address before rolling out a demo, that being daylight saving time, and we'll hit it in detail in the following entry.
- posted by A. Peak @ 5:23 PM

Comments: Post a Comment

<< Home

Actually, reptile7's JavaScript blog is powered by Café La Llave. ;-)

About Me