capturing timezone when parsing java.util.Date

[Lew]

You don't?

By TimeZone you obviously mean java.util.TimeZone which, according to
the API, "represents a time zone offset, and also figures out daylight
savings."

In the general case I suspect you can't get a DST-aware TimeZone from an
offset alone. Consider that Dakar, Casablanca, London, Lisbon, Reykjavík
and Tenerife have the same offset but probably have different policies
for DST.

Heck, until recently the southern part of Indiana in the U.S. had
different policies for DST than the rest of the state. (They didn't
have it at all.)

 

[Lothar Kimmeringer]

Presumably, I need to store both a Date and a TimeZone, but how do I get
the TimeZone from parsing the original String?

As already pointed out by various people you can't get the
timezone from a date containing only the offset. Without
trying it out, at least getting the offset-information might
work like this:

Parse the date using "Z" as pattern and timezone "UTC" using
SimpleDateFormatter. That should return Jan 01 1970 plus or
minus the time the offset was defining, so a date
....+01:00
should return the date
Dec 31 1969 23:00:00 or Jan 01 1970 01:00:00
(I'm too lazy at the moment to think what is correct ;-)

To get the offset it might already be enough to call
getTime() on that date-instance to get the offset in
milliseconds.

Again: I haven't tried that so I might be wrong
Again2: That only gives you the time-offset of that particular
date being parsed. You still have no clue what timezone the
creator of the date was in.


Regards, Lothar
--
Lothar Kimmeringer E-Mail: (e-mail address removed)
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!

 

[Robert Dodier]

public static void main(String[] args) throws ParseException {

  final DateFormat dateFormat =
    new SimpleDateFormat("yyyy-MM-dd HH:mm:ss z");
  dateFormat.parse("2009-06-26 14:13:00 CET");
  System.out.println(dateFormat.getTimeZone().getDisplayName());
  dateFormat.parse("2009-06-26 14:13:00 EST");
  System.out.println(dateFormat.getTimeZone().getDisplayName());

}

Prints:
Central European Time
Eastern Standard Time

Thanks for this. When I try this, it appears that I get my
local time zone if the time zone offset is specified as a
numeric value (e.g. -0400) instead of a alphabetic abbreviation
(e.g. EDT). The values I have to work with have numeric
offsets. I also tried Z instead of z in the format; same behavior.

Thanks for your help,

Robert Dodier

 

[Robert Dodier]

I'm curious what you'll do with the information.

I need to recover the local hour of the day.

FWIW

Robert Dodier

 

[Robert Dodier]

In the general case I suspect you can't get a DST-aware
TimeZone from an offset alone. Consider that Dakar,
Casablanca, London, Lisbon, Reykjavík and Tenerife
have the same offset but probably have different
policies for DST.

OP here. I would be happy enough if I could get some
Java method to parse a numeric offset (along with the
rest of the date).

I don't actually need the timezone, just the offset.
Thanks to those who pointed out the difference.

Robert Dodier

 

[Lew]

Thanks for this. When I try this, it appears that I get my
local time zone if the time zone offset is specified as a
numeric value (e.g. -0400) instead of a alphabetic abbreviation
(e.g. EDT). The values I have to work with have numeric
offsets. I also tried Z instead of z in the format; same behavior.

Does the trick of creating a 'TimeZone' object from the "GHT-04:00"
part of the string work for you? (If all you have is "-04:00" you can
concatenate it to the "GMT".)

 

[Arne Vajhøj]

Maybe it's just me, but I still can't figure out how can
DateFormat.parse() give any sort of information about the time zone or
offset of the date it just parsed.

Id o not return it - it just uses it.

Which kinda surprises me, actually.

Not really the purpose of the class, so it does not surprise me.

Arne

 

[Arne Vajhøj]

Patricia Shanahan wrote:
Even after reading the Javadocs, as well as this discussion, I still

don't know how to deal with the following use-case: Record a date in a
format that allows for time comparisons and adjustments, but display it
appropriately for the original time zone.

It's easy if I want to display all dates in the current locale, or in
some specified locale. I just parse to get a Date, do my comparisons
etc. on that Date object, and then format to the required locale.

It is not so easy, as far as I can tell, if I want to display each date
in its original time zone.

Presumably, I need to store both a Date and a TimeZone,
Obviously.

but how do I get
the TimeZone from parsing the original String?

I would just parse it manually.

Special functionality requires special code.

Arne

 

[Arne Vajhøj]

Even after reading the Javadocs, as well as this discussion, I still
don't know how to deal with the following use-case: Record a date in a
format that allows for time comparisons and adjustments, but display it
appropriately for the original time zone.

Assuming there is original timezone encoded in date/time string:

public static void main(String[] args) throws ParseException {

final DateFormat dateFormat =
new SimpleDateFormat("yyyy-MM-dd HH:mm:ss z");
dateFormat.parse("2009-06-26 14:13:00 CET");
System.out.println(dateFormat.getTimeZone().getDisplayName());
dateFormat.parse("2009-06-26 14:13:00 EST");
System.out.println(dateFormat.getTimeZone().getDisplayName());

}

Prints:
Central European Time
Eastern Standard Time

Very interesting.

I don't like it. It is very bad in my opinion that the parse method
as a side effect changes the Calendar/TimeZone of the DateFormat.

It is not very obvious from the docs either. I wonder whether it is
really a Java feature or an implementation feature.

Arne

 

[John B. Matthews]

I need to recover the local hour of the day.

FWIW

I was trying to imagine a use case, as others have asked above: You're
in the Paris office checking the time stamp on a transaction conducted
at the New York branch. The date & time might be rendered using
TimeZone.getTimeZone("GMT") and Locale.FRANCE. You need to know what the
clock in New York said at that time, perhaps to check a local deadline.
You format the Date with a DateFormat having TimeZone.getTimeZone(
"America/New_York"). Alternatively, you construct a Date based on the
deadline in the New York time zone and compare it to the time stamp.

Something like that?

 

[Arne Vajhøj]

OP here. I would be happy enough if I could get some
Java method to parse a numeric offset (along with the
rest of the date).

That is relative straightforward.

Example:

import java.util.regex.Matcher;
import java.util.regex.Pattern;

public class ManualParse {
private static Pattern re =
Pattern.compile("(?:\\d{4}-\\d{2}-\\d{2}
\\d{2}:\\d{2}:\\d{2})([+-]\\d{4})");
public static int parseOffset(String s) {
Matcher m = re.matcher(s);
if(m.find()) {
String offset = m.group(1);
return Integer.parseInt(offset.substring(0, 3)) * 60 +
Integer.parseInt(offset.substring(3));
} else {
throw new IllegalArgumentException("No offset in string");
}
}
public static void main(String[] args) {
System.out.println(parseOffset("2009-06-26 14:13:00-0400"));
}
}

Arne

 

[Mayeul]

Id o not return it - it just uses it.


Not really the purpose of the class, so it does not surprise me.

Sure, but parsing a Date and the TimeZone it is indicated to use, is the
purpose of which class, then?

Admittedly, it is fairly straightforward to just program it. But,
DateFormat.parse() does parse the time zone or offset information, to
produce the Date object. And then it discards it without any mean to
fetch this information, leaving no choice but to program something to
parse this information again. Not a big deal, but it surprises me.

 

[Mayeul]

Id o not return it - it just uses it.


Not really the purpose of the class, so it does not surprise me.

Sure, but parsing a Date and the TimeZone it is indicated to use, is the
purpose of which class, then?

[snip]

Disregard that. I hadn't read the code snippet that shows
DateFormat.parse() will change the TimeZone associated with the DateFormat.

 

[Robert Dodier]

Something like that?

Actually I am working with physical data for which
local time of day is a factor.

best

Robert Dodier

 

[Dr J R Stockton]

In comp.lang.java.programmer message <9_SdnRn_LruYz9fXnZ2dnUVZ8sidnZ2d@b
t.com>, Tue, 30 Jun 2009 18:57:25, RedGrittyBrick

You don't?

By TimeZone you obviously mean java.util.TimeZone which, according to
the API, "represents a time zone offset, and also figures out daylight
savings."

In the general case I suspect you can't get a DST-aware TimeZone from
an offset alone. Consider that Dakar, Casablanca, London, Lisbon,
Reykjavík and Tenerife have the same offset but probably have different
policies for DST.

They do not have the same offset, it being Northern Summer. And, of
those who do vary their clocks, London does not use "DST" but uses
"Summer Time", and I expect Lisbon does similarly in Portuguese and
Tenerife in Spanish.

Morocco, when last I checked, had unique Time Rules; Iceland is
permanently GMT; Tenerife is Spanish and its clocks always agree with
Lisbon and London.

One can only get a Time Zone from an Offset if the time is known to be
in Winter for that location. If the time is known to be in Summer
there, one also needs to know whether or not the location is LHI.

If one can get a time in January and a time in July, with different
offsets, one can deduce the Hemisphere (N/S) and the Zone - except, in
principle, for any who do not set their clocks forward from Standard
Time in Summer but instead set them back from Standard Time in Winter
(which, after all, is normally shorter). It was thought that the Irish
did that 1972; but they are not nowadays allowed to do so.

I have demonstration code for that, in javaSCRIPT, on my site.

 

[Arne Vajhøj]

Sure, but parsing a Date and the TimeZone it is indicated to use, is the
purpose of which class, then?

Admittedly, it is fairly straightforward to just program it. But,
DateFormat.parse() does parse the time zone or offset information, to
produce the Date object. And then it discards it without any mean to
fetch this information, leaving no choice but to program something to
parse this information again. Not a big deal, but it surprises me.

DateFormat is a class that converts between textual representations
of time and Date which is a true time.

There are no place for returning offset in that.

If there were a TimeOffset and a TimeOffsetFormat class, then ...

But it is not in standard Java. And I don't think it is in JODA
or ICU4J either, so apparently the demand has not been big enough.

Arne

 

[Janin]

No easy way...

I was searching for the answer to this myself, and as it turns out, there is no built-in method to do this. You can do it yourself, but it's difficult because, as others have mentioned, location (country, state, even city), and daylight savings time are a factor. The easiest way to get the actual time zone is to have it stored in the first place.

The only time time zone is needed is to display a time in human-readable form. Otherwise, the UTC time in milliseconds is sufficient to pinpoint a time and use it for comparison.