Calendar.add (DAY_OF_YEAR, 1) - roll not working properly

[Lew]

Actually a good idea.

And it is not as if there is not already deprecated stuff in
the date time stuff.

<https://jsr-310.dev.java.net/nonav/doc-2008-08-04/javax/time/calendar/field/MonthOfYear.html>
Coming soon to a JDK near you.
<https://jsr-310.dev.java.net/nonav/doc-2008-08-04/index.html>

 

[markspace]

<https://jsr-310.dev.java.net/nonav/doc-2008-08-04/javax/time/calendar/field/MonthOfYear.html>

That's a step in the right direction. Too bad they haven't completely
replaced all the methods in the Calendar class:

<https://jsr-310.dev.java.net/nonav/doc-2008-08-04/java/util/Calendar.html>

 

[Arne Vajhøj]

Hmm, I may be mistaken. Stroustrup talks about a Date class in The C++
Programming Language, but it isn't the standard one. He defines a Month
class type like this:

class Date {
public:
enum Month { jan=1, feb, mar, apr, may, jun, jul, aug, sep,
oct, nov, dec };

...
}

So it's not really had to do.

In Java it would have been easy to make a marker interface:

interface Month {}

if nothing else. Although I think extending Iterable would also be useful.

Or if we talk 1.5+ then use enum.

This is a classic case of enum's being more typesafe than int's.

Arne

 

[Arne Vajhøj]

<https://jsr-310.dev.java.net/nonav/doc-2008-08-04/javax/time/calendar/field/MonthOfYear.html>

No surprise.

The idea is obvious.

But based on:

https://jsr-310.dev.java.net/nonav/doc-2008-08-04/javax/time/calendar/LocalDate.html

it looks as if they will support both enum and int.

Coming soon to a JDK near you.
<https://jsr-310.dev.java.net/nonav/doc-2008-08-04/index.html>

I prefer yesterday over tomorrow when it is about Java 7.

Arne

 

[markspace]

Or if we talk 1.5+ then use enum.

This is a classic case of enum's being more typesafe than int's.

Type safe yes, but maybe not more practical.

Just to meander on with the conversation a bit, enum's have some
disadvantages, among which are they are final. You can't extend an
existing month class if they're enums.

I'd support a factory method that makes month types from an enum. That
would be very practical. Something like:

enum MyMonths { Jan, Feb, Mar, ... }

Month myMonths = AbstractMonth.newMonths( MyMonths.class ); // factory

Along with an interface "Month" and a default implementation
"AbstractMonth" to support it.

But making "Month" and actual enum would prevent a programmer from
extending an existing Month and tweaking it a bit to suit his or her
needs. I can't think of a good reason to do this, but I can't think of
a good reason to prevent it either, so I'd personally leave it extensible.

 

[Lars Uffmann]

You had a problem, you asked a question, you got an answer
and you became a wiser person. Happy ending. End of story.

Hehe - nuff said

 

[Lars Uffmann]

What they could have done for 1.5, and certainly no later than 1.6, is
deprecate every Calendar setter method that uses ints, and introduce
parallel versions that use real enums. That way new code could use

Oh yes! The word "deprecated" definitely catches my eye in every
documentation - I wanna be anything but old-fashiond

Regards,

Lars

 

[Arne Vajhøj]

Type safe yes, but maybe not more practical.

Just to meander on with the conversation a bit, enum's have some
disadvantages, among which are they are final. You can't extend an
existing month class if they're enums.

And when would you need that?

I'd support a factory method that makes month types from an enum. That
would be very practical. Something like:

enum MyMonths { Jan, Feb, Mar, ... }

Month myMonths = AbstractMonth.newMonths( MyMonths.class ); // factory

Along with an interface "Month" and a default implementation
"AbstractMonth" to support it.

But making "Month" and actual enum would prevent a programmer from
extending an existing Month and tweaking it a bit to suit his or her
needs. I can't think of a good reason to do this, but I can't think of
a good reason to prevent it either, so I'd personally leave it extensible.

Sue, but it looks like over engineering to me.

Arne

 

[Arne Vajhøj]

The integer-based methods are handy when you are parsing a date from
numerical format, i.e. converting "2009/11/30" to a Date instance
representing November 30th, 2009. You can use DateFormat (and
SimpleDateFormat) for such parsing, but it is sometimes inconvenient
(sometimes, the format which you expect and the amount of leniency you
want to apply do not match what DateFormat offers). If you do it
manually, then you have the month as an int, and you want to input it
that way.

Then supply a UtilsForRareOccasions.intToMonthEnum or something
similar.

Arne

 

[Roedy Green]

Is anyone able to tell me how I can tell this Calendar class to do
proper date calculation?

One way is to use BigDate. I was so frustrated with the bugs and
"features" of Date I wrote BigDate. The main difference is BigDate
works on pure dates, not timestamps.

http://mindprod.com/products1.html#COMMON11

 

[Dr J R Stockton]

In comp.lang.java.programmer message <[email protected]>,

Is anyone able to tell me how I can tell this Calendar class to do
proper date calculation? I don't want to do everything by hand,
accounting for leap years - I just want to add a certain amount of days
to a date and get the date of the result...

Gregorian Date day arithmetic is trivial if one has arithmetical
routines to convert between a Y M D triple and a day-count. A variety
of algorithms for that, with tests, in JavaScript, can be found in
<URL:http://www.merlyn.demon.co.uk/daycount.htm> ; translation to Java
should be easy for anyone who knows and can run Java.

Any Java library with Date routines should provide, and document,
corresponding conversions, carefully avoiding any need to determine
Summer Time either implicitly or explicitly.

Month arithmetic is trivial by converting to/from month-count, except
that one must decide what to do if the starting day number is too large
for the finishing month.

Year arithmetic is trivial, except that one must decide what to do if
the starting date is February 29 and the finishing year is not leap.

Rarely will it be possible to code *significantly* briefer or faster.

 

[Arne Vajhøj]

In comp.lang.java.programmer message <[email protected]>,


Gregorian Date day arithmetic is trivial if one has arithmetical
routines to convert between a Y M D triple and a day-count. A variety
of algorithms for that, with tests, in JavaScript, can be found in
<URL:http://www.merlyn.demon.co.uk/daycount.htm> ; translation to Java
should be easy for anyone who knows and can run Java.

Any Java library with Date routines should provide, and document,
corresponding conversions, carefully avoiding any need to determine
Summer Time either implicitly or explicitly.

Month arithmetic is trivial by converting to/from month-count, except
that one must decide what to do if the starting day number is too large
for the finishing month.

Year arithmetic is trivial, except that one must decide what to do if
the starting date is February 29 and the finishing year is not leap.

Rarely will it be possible to code *significantly* briefer or faster.

If you read the rest of the thread then you will see that the
problem was not lack of functionality but the fact that the OP
did not notice the fine print in the docs saying month's
in Java is zero based so that month 4 is May.

Arne

 

[Arne Vajhøj]

One way is to use BigDate. I was so frustrated with the bugs and
"features" of Date I wrote BigDate. The main difference is BigDate
works on pure dates, not timestamps.

http://mindprod.com/products1.html#COMMON11

When will we see:

http://mindprod.com/dontwriteyourowncodeforfunctionalityinstandardjavaapi.html

?

Arne

 

[Dr J R Stockton]

In comp.lang.java.programmer message <[email protected]

If you read the rest of the thread then you will see that the
problem was not lack of functionality but the fact that the OP
did not notice the fine print in the docs saying month's
in Java is zero based so that month 4 is May.

And that problem would not have occurred of routines such as I described
had been used.

The general problem is that of having routines with too much
functionality for ordinary needs, and with unexpected behaviour
embedded.

Please retain or replace paragraph spacing in quoted material.

 

[Arne Vajhøj]

In comp.lang.java.programmer message<[email protected]


And that problem would not have occurred of routines such as I described
had been used.

The general problem is that of having routines with too much
functionality for ordinary needs, and with unexpected behaviour
embedded.

No.

It is unavoidable to have to be able to specify a month.

The only two points are:
1) programmers need to read the docs
2) Java should have made months 1 based instead of 0 based
(or made them non-integer)

Arne