Simplified TimeZone

[Lord Zoltar]

I am using a DateFormat with the following formate: "hh:mm aa (zz)
MMMM dd, yyyy"
The problem is that "(zz)" will return the current time zone as "EDT"
or "EST". Is there another format that can be used to get to return
"ET", and ignore the indicator of Standard/Daylight savings time?

 

[John B. Matthews]

I am using a DateFormat with the following formate: "hh:mm aa (zz)
MMMM dd, yyyy"
The problem is that "(zz)" will return the current time zone as "EDT"
or "EST". Is there another format that can be used to get to return
"ET", and ignore the indicator of Standard/Daylight savings time?

You might look at getDisplayName(boolean daylight, int style):

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

 

[Lord Zoltar]

You might look at getDisplayName(boolean daylight, int style):

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

getDisplayName(false, TimeZone.SHORT) returns "EST" to me and
getDisplayName(true, TimeZone.SHORT) returns "EDT". What I really need
to display is just "ET". I guess I could always just remove the middle
character or remove any S/D, but I don't know if that would break any
timezones besides Eastern Time.

 

[Andreas Leitgeb]

getDisplayName(false, TimeZone.SHORT) returns "EST" to me and
getDisplayName(true, TimeZone.SHORT) returns "EDT". What I really need
to display is just "ET". I guess I could always just remove the middle
character or remove any S/D, but I don't know if that would break any
timezones besides Eastern Time.

Reading "ET", I'd think "what? extraterrestial time?"

You can, of course, (if you're sure that the users of your
program won't think that way), store the result of
getDisplayName(...) in a variable (tz) and then do:
if (tz.equals("EST") || tz.equals("EDT")) { tz="ET"; }

I'd rather refrain from meddling with these internationally
recognized abbreviations.

 

[Lew]

getDisplayName(false, TimeZone.SHORT) returns "EST" to me and
getDisplayName(true, TimeZone.SHORT) returns "EDT". What I really need
to display is just "ET". I guess I could always just remove the middle
character or remove any S/D, but I don't know if that would break any
timezones besides Eastern Time.

From the Javadocs:

 

[Lord Zoltar]

Reading "ET", I'd think "what? extraterrestial time?"

That's what I though too the first time, and that joke has been used
at least 4 times since we first saw this requirement. I'm amazed it
hasn't gotten old yet.

You can, of course, (if you're sure that the users of your
program won't think that way),  store the result of
getDisplayName(...) in a variable (tz) and then do:
if (tz.equals("EST") || tz.equals("EDT")) { tz="ET"; }

I'd rather refrain from meddling with these internationally
recognized abbreviations.

Neither do I, but it looks like Java doesn't have a way to remove the
Daylight savings/Standard indicator (D or S). I guess another option
would be mapping tables... for every time zone.

 

[Lew]

Are these abbreviations really "internationally recognized"? What is
the standard? Can you point us to any references for more information
on that?

The quote from the Javadocs cited upthread,

... other three-letter time zone IDs (such as "PST", "CTT", "AST")
are ... deprecated because the same abbreviation is often used for
multiple time zones

seems to indicate otherwise. Looking up "standard" abbreviations I
found a list at
<http://www.timeanddate.com/library/abbreviations/timezones/>
which only claims that the abbreviations they list are used "in some
regions of the world". That site lists two expansions for EDT (UTC+11
and UTC-4) three for EST (UTC+10, UTC+11 and UTC-5), and none for ET.

 

[John B. Matthews]

That's what I though too the first time, and that joke has been used
at least 4 times since we first saw this requirement. I'm amazed it
hasn't gotten old yet.


Neither do I, but it looks like Java doesn't have a way to remove the
Daylight savings/Standard indicator (D or S). I guess another option
would be mapping tables... for every time zone.

If you really have a compelling reason to do this anyway, the list isn't
that long:

$ javac Timezone.java ; java Timezone | sort | grep "[A-Z]D[A-Z]"
CST6CDT: Central Standard Time
EST5EDT: Eastern Standard Time
MST7MDT: Mountain Standard Time
PST8PDT: Pacific Standard Time
SystemV/AST4ADT: Atlantic Standard Time
SystemV/CST6CDT: Central Standard Time
SystemV/EST5EDT: Eastern Standard Time
SystemV/MST7MDT: Mountain Standard Time
SystemV/PST8PDT: Pacific Standard Time
SystemV/YST9YDT: Alaska Standard Time

<code>
import java.util.TimeZone;
public class Timezone {
public static void main(String[] args) {
String[] tza = TimeZone.getAvailableIDs();
for (int i = 0; i < tza.length; i++) {
String name = TimeZone.getTimeZone(tza).getDisplayName();
System.out.println(tza + ": " + name);
}
}
}
</code>

 

[John B. Matthews]

Too bad for the Australians.

Good reasons not to monkey with other people's time zone abbreviations.

 

[Andreas Leitgeb]

Are these abbreviations really "internationally recognized"? What is
the standard? Can you point us to any references for more information
on that?

I didn't make a scientific study on it, but if it weren't,
then a time-stamp like: Thu Sep 25 10:33:55 CEST 2008
(from "date") wouldn't be all that useful.

But then again, who knows, perhaps it indeed isn't...

For me, two letter words in a timestamp (except for "ET")
make me speculate about some other language's "am/pm" equivalent.

 

[John B. Matthews]

I didn't make a scientific study on it, but if it weren't,
then a time-stamp like: Thu Sep 25 10:33:55 CEST 2008
(from "date") wouldn't be all that useful.

[...]

Would it make sense to view these abbreviations as "locally recognized?"
If I get up on Christmas morning in Sydney, Ohio, I interpret EST to
mean Eastern Standard Time. My friend Phil in Sydney, Australia
interprets EST as Eastern Summer Time:

Dec 25, 2008 07:00:00 EST; UTC-0500; Sydney, Ohio
Dec 25, 2008 23:00:00 EST; UTC+1100; Sydney, Australia

[It'd be noon in Sydney, England, but I don't know anyone there.]

 

[Dr J R Stockton]

Are these abbreviations really "internationally recognized"?  What is
the standard?  Can you point us to any references for more information
on that?

I believe that anything (unless specifically for the lower end of the
US/CA market) which recognises time offset abbreviations will
recognise 'UTC' and 'GMT'. Nothing else is safe over all systems and
locations (except when built into code which is fully compiled before
distribution). For example, the browser Opera does not recognise
'EST', which is why some NASA Web event countdowns will be wrong in
Opera except when/where local time is equivalent to US EST.

I know of two meanings for EST, three for BST, three for IST.

 

[Dr J R Stockton]

Good reasons not to monkey with other people's time zone abbreviations.

Whatever Java documentation may call them, (US) EST EDT etc. are not
time zones; though ET could be. They are time offset aindications.

Time Zones are geographically fixed, except when changed by
politicians; they do not change seasonally. See Wikipedia, or a
respectable printed dictionary.

 

[Mark Space]

Would it make sense to view these abbreviations as "locally recognized?"
If I get up on Christmas morning in Sydney, Ohio, I interpret EST to
mean Eastern Standard Time. My friend Phil in Sydney, Australia
interprets EST as Eastern Summer Time:

Interesting. Does "Eastern" here mean eastern Australia or eastern US
coast? Just curious....

Dec 25, 2008 07:00:00 EST; UTC-0500; Sydney, Ohio
Dec 25, 2008 23:00:00 EST; UTC+1100; Sydney, Australia

[It'd be noon in Sydney, England, but I don't know anyone there.]

 

[John B. Matthews]

Whatever Java documentation may call them, (US) EST EDT etc. are not
time zones;

Of course not. They are abbreviations used to signify the seasonally
adjusted time in a geographic time zone. They are unambiguous only in
(or near) the corresponding locale.

though ET could be.

For what locale or zone(s)?

They are time offset aindications.

As you suggested, UTC with a numeric offset has a much more widely
understood meaning.

[...]

 

[Dr J R Stockton]

Of course not. They are abbreviations used to signify the seasonally
adjusted time in a geographic time zone. They are unambiguous only in
(or near) the corresponding locale.


For what locale or zone(s)?

It *could* be for the zone which in part alternately uses EST and
EDT. Most zones can be identified by a single letter, as used by the
US military; 25 letters, excluding J, for offsets -12 to +12 hours
from GMT. That must cause problems when invading places whose offsets
that does not cover.

As you suggested, UTC with a numeric offset has a much more widely
understood meaning.

No. That's true, but it is not what I wrote.

 

[Andreas Leitgeb]

That must cause problems when invading places whose offsets
that does not cover.

Especially when thusly missing that place's usual tea-time?

 

[John B. Matthews]

Interesting. Does "Eastern" here mean eastern Australia or eastern US
coast? Just curious....

It depends. That's what I meant by "locally recognized." Phil and I both
see "EST" from SimpleDateFormat("zzz"), but each would be wrong to
interpret the other's abbreviation as if it were local. They are "locale
specific," as described in the Javadocs.

As I prepare to call Phil with Christmas greetings, I check the time in
TimeZone.getTimeZone ("Australia/Sydney") and see that it's nearly
midnight. I mention how we enjoyed the Vegemite he brought on his last
visit; we hang up, because it's costing a fortune. I see his clock says
EST, but I understand that's Eastern Summer Time down under.
[...]

If I'm looking at a local event, the locale specific abbreviation makes
sense; if I'm looking at world events, a SimpleDateFormat that includes
"'UTC'Z'" is much easier to read.

 

[John B. Matthews]

No. That's true, but it is not what I wrote.

[...]

You wrote, "I believe that anything [...] which recognises time offset
abbreviations will recognise 'UTC' and 'GMT'."

Can you elaborate? I understand that UTC derives from international
atomic time, while GMT relates to the Earth's rotation. I thought that
Greenwich was on UTC:

<http://www.parliament.the-stationery-office.co.uk/pa/ld199798/ldhansrd/v
o970611/text/70611-10.htm>

 

[Dr J R Stockton]

<40750cd0-17d0-4011-9244-b5adde807...@p25g2000hsf.googlegroups.com>,

You wrote, "I believe that anything [...] which recognises time offset
abbreviations will recognise 'UTC' and 'GMT'."

(by which I did not mean that "GMT -0500" would be acceptable)

Can you elaborate? I understand that UTC derives from international
atomic time, while GMT relates to the Earth's rotation. I thought that
Greenwich was on UTC:

As far as I know, legal time in the UK is still GMT, because
applicable legislation has not been changed to UTC. UK time signals,
however, are UTC. Many EU countries are legally on UT. Astromomers
will use whichever of the various types of time match the needs of
their work.

For details, search the Web - or try Wikipedia, or use links on my
site.

/Cognoscenti/ deprecate GMT nowadays (UT (2 letters) is the nearest
approved notation) but /hoi polloi/ understand it.

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.
In practice, GMT is time with 24*60*60 seconds per day, with the
length of the second sometimes slightly adjusted so that the GMT and
UTC days average the same.