Date problem

[sne]

I have a date in format DD-MON-YYYY which is stored in a string
I have to retrieve the day,month and year in characters as well as
numbers from the same.please help me with the same
Thanks

 

[Ingo R. Homann]

Hi sne,

I have a date in format DD-MON-YYYY which is stored in a string
I have to retrieve the day,month and year in characters as well as
numbers from the same.please help me with the same
Thanks

Take a look at java.text.SimpleDateFormat.

Hth,
Ingo

 

[sne]

Hi Ingo

Thanks for yr reply.. bt its not wrking.. the date is not coming in
proper format

 

[Ingo R. Homann]

Hi,

Hi Ingo

Thanks for yr reply.. bt its not wrking.. the date is not coming in
proper format

Can you post a SSCCE (code snippet)?

Ciao,
Ingo

 

[sne]

Hey
Hers is the code
String dateStr = "09-May-2006";
Date date = null;
SimpleDateFormat sdf = new SimpleDateFormat("dd-MMMM-yyyy");
try
{
date = sdf.parse(dateStr);
}catch(Exception e){}
java.sql.Date sqlDate = new java.sql.Date(date.getTime());

//java.sql.Date sqlDate = new java.sql.Date(date.getTime());
System.out.println("date "+sqlDate.getDate());
System.out.println("datemonth "+sqlDate.getMonth());
System.out.println("dateyear "+sqlDate.getYear());

The output is:date-9,datemonth-4,dateyear-106 which is wrong

 

[Ingo R. Homann]

Hi,

Hey
Hers is the code
String dateStr = "09-May-2006";
Date date = null;
SimpleDateFormat sdf = new SimpleDateFormat("dd-MMMM-yyyy");
try
{
date = sdf.parse(dateStr);
}catch(Exception e){}
java.sql.Date sqlDate = new java.sql.Date(date.getTime());

//java.sql.Date sqlDate = new java.sql.Date(date.getTime());
System.out.println("date "+sqlDate.getDate());
System.out.println("datemonth "+sqlDate.getMonth());
System.out.println("dateyear "+sqlDate.getYear());

The output is:date-9,datemonth-4,dateyear-106 which is wrong

Well, the day-of-month is OK.

The month is OK as well, although it is *quite* confusing that
Calendar.JANUARY is defined as 0 and not as 1. So you have to add 1 to
every month. (IMHO that is a heavy design-*bug*!)

The year seems to have a Y2K-Bug... Adding 1900 will solve it (although
I thought that this should not be necessary... which JDK-version are you
using?)

Ciao,
Ingo

 

[Simon]

The month is OK as well, although it is *quite* confusing that

Calendar.JANUARY is defined as 0 and not as 1. So you have to add 1 to
every month. (IMHO that is a heavy design-*bug*!)

Why is this a bug? I would say printing the return values of the getter methods
directly is a design bug because that doesn't allow for localisation etc.

The year seems to have a Y2K-Bug... Adding 1900 will solve it (although
I thought that this should not be necessary... which JDK-version are you
using?)

From http://java.sun.com/j2se/1.5.0/docs/api/java/util/Date.html#getYear():

getYear

@Deprecated
public int getYear()

Deprecated. As of JDK version 1.1, replaced by Calendar.get(Calendar.YEAR) -
1900.

Returns a value that is the result of subtracting 1900 from the year that
contains or begins with the instant in time represented by this Date object, as
interpreted in the local time zone.

Returns:
the year represented by this date, minus 1900.
See Also:

 

[Ingo R. Homann]

Hi,

Why is this a bug?

Because everyone would think that it is specified different. E.g. when
you want the user to enter a month (e.g. "6" for "June"), then you
cannot set this month with

calendar.setMonth(m)

but instead you have to use

calendar.setMonth(new Calender(new
SimpleDateFormat("MM").format(m).getTime()).get(Calendar.MONTH))

or something like that (I guess it gets even more complicated because
there is no such constructor for Calender)...

You could design a programming language whose array-indices start with
-3, that would make as much sense.

Ciao,
Ingo

 

[Simon]

Because everyone would think that it is specified different. E.g. when
you want the user to enter a month (e.g. "6" for "June"), then you
cannot set this month with

calendar.setMonth(m)

but instead you have to use

calendar.setMonth(new Calender(new
SimpleDateFormat("MM").format(m).getTime()).get(Calendar.MONTH))

or something like that (I guess it gets even more complicated because
there is no such constructor for Calender)...

Well, you are right, this is very clumsy. But if you know that the user inputs
the month as a number, then why don't you just use calendar.setMonth(m-1)?

Also, in your example, you omitted a line of code: In general, I would assume
that the user has entered a *string*, so you have to use a parser anyway to make
it a month. Using Integer.parseInt(String) is the wrong decision anyway because
it returns an integer and not a month. Hence, you need to replace it by
DateFormat.parse(String)
On the other hand, if you use a combo box or something, you can get the indices
right in the first place. Then, starting with 0 is making it easier, I think.

Apart from that, I have never encountered an application where the user enters
*only* a month, and if he enters a whole date you need a DateFormat anyway.

You could design a programming language whose array-indices start with
-3, that would make as much sense.

So you want array-indices to start with 1? I don't see the analogy.

Making January=0 was a design decision which has advantages and disadvantages. I
would not consider it a heavy bug, though.

Cheers,
Simon

 

[Ingo R. Homann]

Hi,

Well, you are right, this is very clumsy. But if you know that the user inputs
the month as a number, then why don't you just use calendar.setMonth(m-1)?

In fact, I'm doing it the way you mention.

But I am aware that this is the worst of both worlds: (1) It works aroud
(i.e. does not work with) localisation and (2) at first glance one could
wonder "Why does he want to take the previous month and not the month
entered?"

Apart from that, I have never encountered an application where the user enters
*only* a month, and if he enters a whole date you need a DateFormat anyway.

Oh well, I am programming a financial application where dues have to be
paid every month. So, in the database there is stored the year (as int)
and the month (as int). (It does not make sense to store that both
together in a field of type 'date' because the 'day' is obsolete.) Now,
when retrieving datasets from the database, of course, '1' means
'JANUARY'. When I want to print a notification/bill, I want to say "The
dues have to be paid until 15 of January 2007". So, I need to convert
the (int,int) to a Date. This occurs on several places...

So you want array-indices to start with 1? I don't see the analogy.

No - I'm saying that an array-indes starting with something other that
the common '0' makes as much sense as defining JANUARY as something
other that the common '1'.

Making January=0 was a design decision which has advantages and disadvantages. I
would not consider it a heavy bug, though.

Eh... I do not see *any* advantage until now!

Ciao,
Ingo

 

[Simon]

Eh... I do not see *any* advantage until now!

* forcing users to use localization

* Imagine you want to present a combo box that lets the user select a month, the
current month being preselected. How do you do this? I would write

static final String[] MONTHS = {"January", "February", ... };
JComboBox dateBox = new JComboBox(MONTHS);
dateBox.setSelectedIndex(calendar.get(Calendar.MONTH));
....
calendar.set(Calendar.MONTH, dateBox.getSelectedIndex());
print("You selected "+MONTHS[dateBox.getSlectedIndex()]);

Starting numbering with one you would have to either define
MONTHS = { "UNUSED", "January", "February", ...}
and prevent it from going into the ComboBox or add one in several places.

Cheers,
Simon

 

[Oliver Wong]

So you want array-indices to start with 1? I don't see the analogy.

It's the princple of least surprise. When you design something, you want
to surprise your users as little as possible. To me, it's quite surprising
that 5 refers to June and not May, for example. For array-indices, starting
at 1 or 0 is okay (both makes sense), but -3 or 42 or anything else would be
quite surprising as well.

- Oliver