What do people use to parse datetimes?

A

Andrew

Hello,

I have just discovered that joda does not parse datetimes that contain
timezones. Hence I am forced to use the date parsing routines in
java.util. But they do not seem to handle bad dates. For example,
2008-13-01 parses as if it was 2008-01-01. I can even give it the 30th
of February and it says ths is ok!

What do people use to parse datetimes please? I am looking for
something that will not accept invalid dates and that handles
timezones, whether specified as timezone name or offset from UTC (as
per ISO 8601).

Regards,

Andrew Marlow
 
L

Lew

Hello,

I have just discovered that joda does not parse datetimes that contain
timezones. Hence I am forced to use the date parsing routines in
java.util. But they do not seem to handle bad dates. For example,
2008-13-01 parses as if it was 2008-01-01. I can even give it the 30th
of February and it says ths is ok!

What do people use to parse datetimes please? I am looking for
something that will not accept invalid dates and that handles
timezones, whether specified as timezone name or offset from UTC (as
per ISO 8601).

Always read the Javadocs!

If you use 'java.util.Calendar' you might be interested in
<http://java.sun.com/javase/6/docs/api/java/util/
Calendar.html#setLenient(boolean)>

You failed to tell us what classes and methods you used to parse
dates, and what you were parsing (presumably String values). Assuming
you're using java.text.DateFormat to parse those strings, you want:
<http://java.sun.com/javase/6/docs/api/java/text/
DateFormat.html#setLenient(boolean)>
<http://java.sun.com/javase/6/docs/api/java/text/DateFormat.html#parse
(java.lang.String)>
"By default, parsing is lenient: If the input is not in the form used
by this object's format method but can still be parsed as a date, then
the parse succeeds. Clients may insist on strict adherence to the
format by calling setLenient(false)."
 
R

Roedy Green

What do people use to parse datetimes please? I am looking for
something that will not accept invalid dates and that handles
timezones, whether specified as timezone name or offset from UTC (as
per ISO 8601).

You can parse them with a SimpleDateFormat. See
http://mindprod.com/jgloss/calendar.html

If you run out of steam, you can always use a generic regex.
See http://mindprod.com/jgloss/regex.html
--
Roedy Green Canadian Mind Products
http://mindprod.com

"The industrial civilisation is based on the consumption of energy resources that are inherently limited in quantity, and that are about to become scarce. When they do, competition for what remains will trigger dramatic economic and geopolitical events; in the end, it may be impossible for even a single nation to sustain industrialism as we have know it in the twentieth century."
~ Richard Heinberg, The Party’s Over: Oil, War, and the Fate of Industrial Societies
 
A

Arne Vajhøj

Andrew said:
I have just discovered that joda does not parse datetimes that contain
timezones. Hence I am forced to use the date parsing routines in
java.util. But they do not seem to handle bad dates. For example,
2008-13-01 parses as if it was 2008-01-01. I can even give it the 30th
of February and it says ths is ok!

What do people use to parse datetimes please? I am looking for
something that will not accept invalid dates and that handles
timezones, whether specified as timezone name or offset from UTC (as
per ISO 8601).

SimpleDateFormat works fine for me.

Arne
 
A

alexandre_paterson

Hello,

I have just discovered that joda does not parse datetimes that contain
timezones.

?

Are you *sure* about that?

Joda Time DateTimeFormat and DateTimeFormatter support timezones.

Hence I am forced to use the date parsing routines in java.util.

Should your assertion be true, you'd certainly not be 'forced'
to use the "date parsing routine in java.util" [sic].


You could easily parse the date yourself and feed it to Joda using the
y/m/d/h/m/s and the correct timezone.

And then make your parser handle what you consider "bad dates" the
way you want?

Been there, done that, before knowing about Joda's DateTimeFormat
(ter) :)

For example:

final DateTimeZone dtz = DateTimeZone.forID( "America/New_York" );
final DateTime dt = new DateTime( y, month + 1, d, h, min, sec, 0,
dtz );

Of course you have to modify your DateTimeZone accordingly to
what you have parsed.
 
A

Andrew

You can parse them with a SimpleDateFormat. Seehttp://mindprod.com/jgloss/calendar.html

Unfortunately not. This only works in very simple cases. The reason is
that SimpleDateFormat works using a format specifier and ISO8601 has
many formats and rules. These cannot be expressed with one simple
format string from the list that SimpleDateFormat supports.

-Andrew Marlow
 
A

Andrew

You could easily parse the date yourself and feed it to Joda using the
y/m/d/h/m/s and the correct timezone.

Well, yes, having found that the std off the shelf solution does not
work I could code the solution myself. But this must be such a
commonly recurring problem I thought there would be an off the shelf
solution. However, after searching for a while I find that various
groups and projects eventually code their own solutions. Oracle has
one, so does NASA. Unfortunately these and others are closed source.
Looks like I had better start coding.

-Andrew Marlow
 
A

Andrew

Hello,

I have just discovered that joda does not parse datetimes that contain
timezones. Hence I am forced to use the date parsing routines in
java.util. But they do not seem to handle bad dates. For example,
2008-13-01 parses as if it was 2008-01-01. I can even give it the 30th
of February and it says ths is ok!

What do people use to parse datetimes please? I am looking for
something that will not accept invalid dates and that handles
timezones, whether specified as timezone name or offset from UTC (as
per ISO 8601).

Regards,

Andrew Marlow

The example test program below shows some of the problems encountered
by using the Joda DateTime with explicit use of the ISOChronology.
Hopefully this will satisify the sckeptics that there is indeed a
problem with joda datetimes and ISO8601. Note that the program uses
the ISO chronology rather than a datetime formatter because the
formatter does not cover all ISO8601 cases and is documented as not
working properly wrt timezones.

import org.joda.time.DateTime;
import org.joda.time.DateTimeZone;
import org.joda.time.chrono.ISOChronology;

public class Iso8601Test {

public void test() {
checkDateTime("2009-06-30T13:45:04", 2009, 6, 30, 13, 45,
4);

// with GMT offsets
checkDateTimeWithOffset("2009-06-30T13:45:04+00:00", 2009, 6,
30, 13, 45, 4, 0);
checkDateTimeWithOffset("2009-06-30T13:45:04+01:00", 2009, 6,
30, 13, 45, 4, 1);
checkDateTimeWithOffset("2009-06-30T13:45:04+05:00", 2009, 6,
30, 13, 45, 4, 5);
checkDateTimeWithOffset("2009-06-30T13:45:04+09:00", 2009, 6,
30, 13, 45, 4, 9);
checkDateTimeWithOffset("2009-06-30T13:45:04-03:00", 2009, 6,
30, 13, 45, 4, -3);
checkDateTimeWithOffset("2009-06-30T13:45:04-07:00", 2009, 6,
30, 13, 45, 4, -7);

// bad dates
checkBadStrings("2009-13-30T13:45:04", 2009, 6, 30, 13, 45,
4);
checkBadStrings("2009-02-30T13:45:04", 2009, 6, 30, 13, 45,
4);
}

private void checkDateTime(String dateTimeString,
int yyyy, int mm, int dd,
int hh, int mi, int ss) {
DateTime actualDateTime = new DateTime(dateTimeString,
ISOChronology.getInstance());
DateTime expectedDateTime = new DateTime(yyyy, mm, dd, hh, mi,
ss, 0);
if (actualDateTime.equals(expectedDateTime)) {
System.out.println(String.format("ok, input string = '%s',
converted datetime = %s\n",
dateTimeString,
actualDateTime));
} else {
System.out.println(String.format("failed to convert
properly, input string = '%s'\n"
+ "converted value = %s\n", dateTimeString,
actualDateTime));
}
}

private void checkDateTimeWithOffset(String dateTimeString,
int yyyy, int mm, int dd,
int hh, int mi, int ss, int
offset) {
DateTime actualDateTime = new DateTime(dateTimeString,
ISOChronology.getInstance());
DateTimeZone dateTimeZone = DateTimeZone.forOffsetHours
(offset);
DateTime expectedDateTime = new DateTime(yyyy, mm, dd,
hh, mi, ss, 0,
dateTimeZone);
if (actualDateTime.equals(expectedDateTime)) {
System.out.println(String.format("ok, input string = '%s',
converted datetime = %s\n",
dateTimeString,
actualDateTime));
} else {
System.out.println(String.format("failed to convert
properly, offset = %s, input string = '%s'\n"
+ " converted value = '%s'\n"
+ " expected value = '%s'\n", offset,
dateTimeString, actualDateTime, expectedDateTime));
}
}

public void checkBadStrings(String dateTimeString,
int yyyy, int mm, int dd,
int hh, int mi, int ss) {
try {
DateTime actualDateTime = new DateTime(dateTimeString,
ISOChronology.getInstance());
throw new RuntimeException(String.format("parsed string
'%s' as '%s' when should have got exception", dateTimeString,
actualDateTime));
} catch (org.joda.time.IllegalFieldValueException exception) {
System.out.println("correctly encountered exception for
bad string");
}
}

public static void main(String[] args) {
Iso8601Test app = new Iso8601Test();
app.test();
System.exit(0);
}
}
 
L

Lew

Andrew said:
Unfortunately not. This only works in very simple cases. The reason is
that SimpleDateFormat works using a format specifier and ISO8601 has
many formats and rules. These cannot be expressed with one simple
format string from the list that SimpleDateFormat supports.

Then you use more than one DateFormat. Still simple.
 
L

Lew

Andrew said:
The example test program below shows some of the problems encountered
by using the Joda DateTime with explicit use of the ISOChronology.
Hopefully this will satisify the sckeptics that there is indeed a
problem with joda datetimes and ISO8601. Note that the program uses
the ISO chronology rather than a datetime formatter because the
formatter does not cover all ISO8601 cases and is documented as not
working properly wrt timezones.

Would you care to substantiate that, i.e., by pointing us to the documentation?

I have used [Simple]DateFormat with ISO formats many times, and found it to be
quite satisfactory.
 
D

Dr J R Stockton

In comp.lang.java.programmer message <c45606fa-3478-4ec3-bb09-3644e7ac9f
(e-mail address removed)>, Sun, 26 Jul 2009 06:00:54, Andrew

Timezones do not in general have names used with dates; and those that
exist are not commonly used. Be aware that, by definition, Time Zones
are geographically fixed and do not change regularly between Summer &
winter. Consider New York. It is in the GMT-5 Time Zone, permanently;
that is sometimes called ET, for Eastern Time; but the Australians,
among others, also have an East. In the USA, the acronyms EST and EDT
apply to a single Time Zone, not to two.
Unfortunately not. This only works in very simple cases. The reason is
that SimpleDateFormat works using a format specifier and ISO8601 has
many formats and rules. These cannot be expressed with one simple
format string from the list that SimpleDateFormat supports.

In practice, there will generally be knowledge of which form will be in
use; and a single format string should suffice. Otherwise, it is fairly
east to distinguish between the various formats by using RegExps, I do
it, in JavaScript, in <URL:http://www.merlyn.demon.co.uk/js-dobj2.htm>.
 
A

Andrew

In comp.lang.java.programmer message <c45606fa-3478-4ec3-bb09-3644e7ac9f
(e-mail address removed)>, Sun, 26 Jul 2009 06:00:54, Andrew


Timezones do not in general have names used with dates; and those that
exist are not commonly used.  Be aware that, by definition, Time Zones
are geographically fixed and do not change regularly between Summer &
winter.  Consider New York.  It is in the GMT-5 Time Zone, permanently;
that is sometimes called ET, for Eastern Time; but the Australians,
among others, also have an East.  In the USA, the acronyms EST and EDT
apply to a single Time Zone, not to two.



In practice, there will generally be knowledge of which form will be in
use; and a single format string should suffice.  Otherwise, it is fairly
east to distinguish between the various formats by using RegExps, I do
it, in JavaScript, in <URL:http://www.merlyn.demon.co.uk/js-dobj2.htm>.

Yes. The form in use in my case is that produced by joda DateTime in
its DateTime-to-string conversion. That code produces a string that
expresses the value as UTC plus offset in hours and minutes. To parse
this I use the code:

dateTime result = ISODateTimeFormat.dateTime().withOffsetParsed
().parseDateTime(dateTimeString);

So I have now solved the problem. I also managed (eventually) to find
a copy of the ISO8601 standard instead of having to reply on what
wikipedia says. I find that the ISO std does not mention timezone
names at all. IMO this is because we cannot make general purpose sw
work reliably with them.

Timezone names are ambiguous and change their meanings over time as
various governments change their minds. Timezone names are sometimes
confused with names that are used as a combination of timezone and
daylight savings. The main people that have to worry about this are
system administrators as they struggle to make their machines agree as
to what the time is when daylight savings change etc etc. This is
usually done with a database of timezone and daylight savings
information. The data is grouped by the countries and regions whose
governments assign the various meanings and even a given government
changes its mind over time so these rules have start and end times. It
is my guess that ISO8601 gives up in the face of this and that is why
it always uses numeric offset from UTC. It would be nice if the std
actually said that though. Plus it would be nice if this was more
prominent in the joda documentation. Sadly it isn't. Furthermore, the
joda interface invites you to use timezone names by apparantly having
support for it. It tries to handle them using a timezone database. I
wouldn't go there.....

Regards,

Andrew Marlow
 
D

Dr J R Stockton

In comp.lang.java.programmer message <b82b1c51-a3d5-43ab-bbc9-390fb88a06
(e-mail address removed)>, Wed, 29 Jul 2009 01:16:31, Andrew
So I have now solved the problem. I also managed (eventually) to find
a copy of the ISO8601 standard instead of having to reply on what
wikipedia says.

There is a link to its PDF on my web site, in datefmts.htm - and also
one at the foot of the Wiki page "ISO 8601".

I find that the ISO std does not mention timezone
names at all. IMO this is because we cannot make general purpose sw
work reliably with them.

There is no internationally-accepted definition, except for GMT & UTC.
The same letters are used in different places for different offsets -
for example, BST has 3 meanings.
It
is my guess that ISO8601 gives up in the face of this and that is why
it always uses numeric offset from UTC. It would be nice if the std
actually said that though.

The introduction does say "numeric". Admittedly, the formats allow use
of W & Z.
 
R

RedGrittyBrick

Dr said:
In comp.lang.java.programmer message <b82b1c51-a3d5-43ab-bbc9-390fb88a06
(e-mail address removed)>, Wed, 29 Jul 2009 01:16:31, Andrew


There is a link to its PDF on my web site, in datefmts.htm - and also
one at the foot of the Wiki page "ISO 8601".

In the ISO website, that PDF is offered for sale at CHF 130.
ISO state that selling standards is one of their sources of funding.
 
D

Dr J R Stockton

In comp.lang.java.programmer message <[email protected].
co.uk>, Thu, 30 Jul 2009 12:00:35, RedGrittyBrick <RedGrittyBrick@spamwe
ary.invalid> posted:
In the ISO website, that PDF is offered for sale at CHF 130.
ISO state that selling standards is one of their sources of funding.

Perhaps for 130 CHF they sell the PDF unzipped; they do quote a larger
size. But, if you had read either of the pages that I referred to, you
could have discovered that the free ZIP of the PDF is from the ISO Web
site itself. Thus, they can satisfy both those who want to pay CHF 130
and those who do not.
 
R

RedGrittyBrick

Dr said:
In comp.lang.java.programmer message <[email protected].
co.uk>, Thu, 30 Jul 2009 12:00:35, RedGrittyBrick <RedGrittyBrick@spamwe
ary.invalid> posted:


Perhaps for 130 CHF they sell the PDF unzipped; they do quote a larger
size. But, if you had read either of the pages that I referred to,

I had already read your page and the Wikipedia article.
you
could have discovered that the free ZIP of the PDF is from the ISO Web
site itself. Thus, they can satisfy both those who want to pay CHF 130
and those who do not.

I wondered whether the availability was inadvertent, like a baker who
leaves his cakes to cool in an open window, not expecting that
passers-by will see them and assume they are free to take them.

I would like to see standards made available for free, as the IETF do. I
hesitate about taking things when I am not sure I have the copyright
owners clear consent. I couldn't find any reference on the ISO site to
their intentionally making their standards available for free.
 
R

RedGrittyBrick

Dr said:
In comp.lang.java.programmer message <[email protected].
co.uk>, Thu, 30 Jul 2009 12:00:35, RedGrittyBrick <RedGrittyBrick@spamwe
ary.invalid> posted:


Perhaps for 130 CHF they sell the PDF unzipped; they do quote a larger
size. But, if you had read either of the pages that I referred to, you
could have discovered that the free ZIP of the PDF is from the ISO Web
site itself. Thus, they can satisfy both those who want to pay CHF 130
and those who do not.

SO far as I can see, ISO 8601 is not amongst the freely available
standards listed at
<http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html>

I infer that ISO may not have intended for people to (be able to) take
ISO 8601 without paying.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,773
Messages
2,569,594
Members
45,121
Latest member
LowellMcGu
Top