Simplified TimeZone

[John B. Matthews]

[...]

UTC is atomic time, all seconds identical, with a second added (or
omitted) occasionally at the end of UTC June or December. It is kept
within +-0.9 seconds of Earth Rotation Time. Few computers use it.

[...]

Not directly, of course; but it's widely available from stratum one
NTP servers using GPS:

<URL:http://www.merlyn.demon.co.uk/>

Very informative!

 

[John W Kennedy]

UTC is atomic time, all seconds identical, with a second added (or
omitted) occasionally at the end of UTC June or December. It is kept
within +-0.9 seconds of Earth Rotation Time. Few computers use it.

They do if (as most do) they obtain their time from standard sources
such as the US Naval Observatory. They may /call/ it "GMT", and they may
not insert leap seconds at the correct times (instead picking them up as
data corrections the next time they synchronize), but UTC is the basis
of civil time, and computers normally use it.

/Real/ GMT is quite rare, being essentially limited to atomic clocks and
ephemerides that have not been updated.

 

[Dr J R Stockton]

[...]> UTC is atomic time, all seconds identical, with a second added (or

omitted) occasionally at the end of UTC June or December.  It is kept
within +-0.9 seconds of Earth Rotation Time.  Few computers use it.

[...]

Not directly, of course; but it's widely available from stratum one
NTP servers using GPS:

I meant, of course, "Few computers use it internally". When being set
fron an NTP server, most will IMHO treat its data as "GMT" (i.e.
representing days of 86400 seconds) but one hopes with provision for
tolerating the occasional second numbered 60.


I take care not to be using my computers at 01:00 in the last Sunday
in March or between 01:00 and 02:00 on the last Sunday in October, all
both UTC *and* GMT.

 

[Dr J R Stockton]

Those changeover dates vary with locale.

Almost everybody knows that changover dates vary with location - the
Australians even have Summer in the Winter and /vice versa/ - and can
be changed politically.

But **those** changeover dates do not vary (AFAICS, no EU change is to
be expected, and my computers will remain set to UK time (tests
apart)). If you had read what you responded to until proper
understanding was attained, you would have been aware that I was
writing about what *I* do with *my* computers.

 

[Dr J R Stockton]

I did, and I was.

Then I cannot see what use you could reasonably have considered your
response to be. It would be stupid to consider the averare reader
here to be stupid.

 

[John B. Matthews]

I did, and I was.

Then I cannot see what use you could reasonably have considered your
response to be. It would be stupid to consider the avera[g]e reader
here to be stupid.

Certainly, an unwarranted assumption.

To me, Lew's response seemed informative: "Those changeover dates vary
with locale." In the case of Java, the locale-specific rules are
incorporated in SimpleTimeZone:

<http://java.sun.com/javase/6/docs/api/java/util/SimpleTimeZone.html>

I am disappointed that the class does not offer getStartYear(). The EU
adopted uniform DST transition dates in 1996 [1]; the US did so in 2007
[2]; other locales will change in the future. I would expect your
software vendor to offer updates, accordingly. Such updates would be
essential to correct operation, irrespective of when you use your
computer.

[1, 2] <http://www.seizethedaylight.com/dst/>
[I have edited your message to indicate how I interpreted it.]

 

[Dr J R Stockton]

I am disappointed that the class does not offer getStartYear().

A routine getStartYear() can hardly be entirely satisfactory of
itself. By law, the current US DST rules came into force on
2007-03-01, presumably at 00:00 local. And Northern Hemisphere
practice has commonly, but not invariably, been to change the rules
during the winter; if the Southern Hemisphere does likewise, they are
liable to change rules mid-year, so that in that year the Autumn and
Spring dates use the old & new Rules.

The EU
adopted uniform DST transition dates in 1996 [1]; the US did so in
2007 [2];

But not exactly. EU Summer Time (not DST) Rules became uniform in
1996, whereas US DST Rules had been uniform (but optional) long before
that. Those years are when the current uniform rules started.

other locales will change in the future. I would expect your
software vendor to offer updates, accordingly. Such updates would be
essential to correct operation, irrespective of when you use your
computer.

Not entirely irrespective; one might choose to keep one's computer on
permanent GMT, regardless of locality.

 

[John B. Matthews]

A routine getStartYear() can hardly be entirely satisfactory of
itself.

Yes, I was motivated more by curiosity than practical benefit. Indeed,
on my implementation, the code below reveals that startYear is zero
throughout. Moreover, reflection shows that the (private) TimeZone
parameters do not include a year.

[...]

Not entirely irrespective; one might choose to keep one's computer on
permanent GMT, regardless of locality.

Well, if you live "near London, UK" you already do! I mean if you want
to ring up a friend in an unfamiliar time zone. You ask your computer
what time it is there. The wrong answer will wake the whole house.

<code>
import java.lang.reflect.Field;
import java.util.regex.*;
import java.util.*;
//import sun.util.calendar.ZoneInfo;

public class Timezone {

public static void main(String[] args) {
String[] tza = TimeZone.getAvailableIDs();
Arrays.sort(tza, new Comparator<String>() {
public int compare(String s1, String s2) {
return s1.compareTo(s2);
}
});

Pattern sy = Pattern.compile("^.*(startYear=\\d).*$");
for (int i = 0; i < tza.length; i++) {
TimeZone tz = TimeZone.getTimeZone(tza);
String abbr = tz.getDisplayName(false, TimeZone.SHORT);
String name = tz.getDisplayName(false, TimeZone.LONG);
Matcher m = sy.matcher(tz.toString());
if (m.find()) {
System.out.println(tza
+ " : " + abbr
+ " : " + name
+ " : " + m.group(1));
}
}

printTzParams("Europe/London");
printTzParams("Europe/Zurich");
printTzParams("US/Eastern");
printTzParams("US/Pacific");
}

private static void printTzParams (String id) {
TimeZone tz = TimeZone.getTimeZone(id);
String name = "simpleTimeZoneParams";
final Field fields[] = tz.getClass().getDeclaredFields();
for (int i = 0; i < fields.length; i++) {
if (name.equals(fields.getName())) {
try {
fields.setAccessible(true);
int[] ia = (int[]) fields.get(tz);
System.out.print("Params for "
+ tz.getID() + ": ");
for (int j = 0; j < ia.length; j++) {
System.out.print(ia[j] + " ");
}
System.out.println();
}
catch (IllegalAccessException e) {
System.err.println("IllegalAccess: " + name);
}
}
}
}
}
</code>

 

[Dr J R Stockton]

Well, if you live "near London, UK" you already do!

No; the British Isles (with a small exception : Gur Punaary Ghaary
Grezvany hfrf Serapu Gvzr) uses, for Local Civil Time, GMT in Winter
and BST = GMT+1 in Summer. My computers change accordingly. Howeverm
the oven and the car use GMT permanently (it's too much bother to
change those).

 

[RedGrittyBrick]

Wales, right? Sure looks like it ...

Try ROT13.

 

[Dr J R Stockton]

They do if (as most do) they obtain their time from standard sources
such as the US Naval Observatory. They may /call/ it "GMT", and they may
not insert leap seconds at the correct times (instead picking them up as
data corrections the next time they synchronize), but UTC is the basis
of civil time, and computers normally use it.

No. The time is supplied from a source of UTC, but it is used as GMT,
with 60 +/- 0 seconds on every minute.

To say that a PC uses UTC is like saying that a car is driven by its
starter motor.

And here, legal time is GMT-based, although time signals are UTC.

You may know that true DOS, when running, relies on the 18.2 Hz
software clock at $40:$6C, with $1800B0 ticks per day. The source of
a DOS clone shows that directly after a tick the counter is checked
for being $1800B0; if so, it is set to zero for the new day.

I tested setting it by other means to $1800B0. Time-of-Day continued
increasing, 24:00:00, 24:00:01, ..., 24:01:00, ..., 25:00:00, ... but
as it increased various pieces of software began to fail. A better-
designed OS would have used a .GE. test ratner than a .EQ. . But that
clearly shows a case where accepting a valid UTC time that was not a
valid GMT time could have lead to disaster.

 

[John W Kennedy]

No. The time is supplied from a source of UTC, but it is used as GMT,
with 60 +/- 0 seconds on every minute.

But the actual time that they use is UTC, which differs from GMT at
present by 23 seconds.

--
John W. Kennedy
"You can, if you wish, class all science-fiction together; but it is
about as perceptive as classing the works of Ballantyne, Conrad and W.
W. Jacobs together as the 'sea-story' and then criticizing _that_."
-- C. S. Lewis. "An Experiment in Criticism"

 

[RedGrittyBrick]

Is there an official source of GMT anymore?

AIUI The Royal Observatory at Greenwich was established in 1675 to
maintain and supply the GMT reference but no longer do so. If you go to
their website you end up at

<http://preview.tinyurl.com/4e64dg>
which says
"Today GMT is more correctly referred to as Coordinated Universal Time
(UTC). "

It is likely, of course, that this is a simplification aimed at what JRS
refers to as "hoi polloi".

AIUI UT is the practical successor to GMT. There were many successive
ways of defining GMT and this led to problems in using historical
records, hence UT was defined in order that a consistent timescale would
exist with an unvarying meaning and means of definition/measurement.

I suspect that, regardless of what lawyers and politicians might like,
GMT in it's proper sense no longer exists in any usable form.

<http://www.ucolick.org/~sla/leapsecs/timescales.html>

We just casually label UTC as GMT since I guess JRS's "hoi polloi" are
more familiar with "traditional" GMT. Me included.

But the actual time that they use is UTC,
which differs from GMT at
present by 23 seconds.

<http://www.npl.co.uk/server.php?show=ConWebDoc.1058> and many other
sources say UTC and GMT don't differ by more than a second. Perhaps you
mean GPS time?

 

[Dr J R Stockton]

But the actual time that they use is UTC, which differs from GMT at
present by 23 seconds.

It does not. UTC is maintained to be within +-0.9 seconds of UT1
which is within a amall fraction of a second of GMT/UT.

UTC currently differs by 33 seconds from TAI.

Read <http://en.wikipedia.org/wiki/UTC> etc.; and read Paul Schlyter
at <http://stjarnhimlen.se>.

There have been 23 Leap Seconds, all positive. It is those which keep
UTC in agreement with UT1.

AIUI, GPS internally ignores Leap Seconds, but started with
1980-01-06, which is why its 1024-week rollover was at actually at
1999-08-21 23:59:47 UTC (AIUI, some receivers showed errors).