Prev: Using examples in software development
Next: Forcing garbage collection
From: Dr J R Stockton on 5 Dec 2009 12:11
In comp.lang.java.programmer message <4b170544$0$273$14726298(a)news.sunsi
te.dk>, Wed, 2 Dec 2009 19:24:45, Arne Vajh�j <arne(a)vajhoej.dk> posted:
>Dr J R Stockton wrote:
>> In comp.lang.java.programmer message <7ng5mrF3lbplvU1(a)mid.dfncis.de>,
>> Sun, 29 Nov 2009 22:11:22, Lars Uffmann <aral(a)nurfuerspam.de> posted:
>>
>>> 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.
>
>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.

--
(c) John Stockton, nr London UK. replyYYWW merlyn demon co uk Turnpike 6.05.
Web <URL:http://www.uwasa.fi/~ts/http/tsfaq.html> -> Timo Salmi: Usenet Q&A.
Web <URL:http://www.merlyn.demon.co.uk/news-use.htm> : about usage of News.
No Encoding. Quotes precede replies. Snip well. Write clearly. Mail no News.
From: Arne Vajhøj on 3 Jan 2010 20:20
On 05-12-2009 12:11, Dr J R Stockton wrote:
> In comp.lang.java.programmer message<4b170544$0$273$14726298(a)news.sunsi
> te.dk>, Wed, 2 Dec 2009 19:24:45, Arne Vajh�j<arne(a)vajhoej.dk> posted:
>> Dr J R Stockton wrote:
>>> In comp.lang.java.programmer message<7ng5mrF3lbplvU1(a)mid.dfncis.de>,
>>> Sun, 29 Nov 2009 22:11:22, Lars Uffmann<aral(a)nurfuerspam.de> posted:
>>>
>>>> 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.
>>
>> 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.

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
First  |  Prev  | 
Pages: 1 2
Prev: Using examples in software development
Next: Forcing garbage collection