Prev: configure Spring to use jax-ws endpoint to consume XML then produce JSON
Next: Reading from very large file
From: Arne Vajhøj on 9 May 2010 12:50
On 08-05-2010 10:01, Eric Sosman wrote:
> On 5/7/2010 10:12 PM, Arne Vajh�j wrote:
>> On 07-05-2010 15:41, olegkon wrote:
>>> I am looking for some Web Service / JavaBean / Java lib
>>> which would be able to determine whether particular day (e.g. today)
>>> is a Business Day in Financial industry
>>> (e.g. Banking) and be callable from Java program.
>>
>> That is country specific.
>
> It's even more specific than that. I live in the United States,
> in the Commonwealth of Massachusetts. In these parts, the Monday
> closest to April 19 is a holiday (Patriots' Day) commemorating the
> initial hostilities of the American Revolution. But elsewhere in
> the country, the occasion goes largely unobserved: So it's a holiday
> here and a "business day" most everywhere else.
>
> Even on the holiday, some businesses operate and some do not.
> Federal government offices are open, state and city offices are
> closed (you can't appeal your real estate tax assessment at City
> Hall, but you can mail the tax payment via the Federally-operated
> Postal Service). Private businesses are open or closed in accordance
> with a crazy quilt of regulation and tradition. A foot race called
> the Boston Marathon runs through my town that day, bringing nearly
> everything but the runners to a halt -- except that the policemen,
> firemen, and emergency personnel of all kinds are *all* on duty;
> it's no holiday for them ...
>
> Similar variations can be found in other countries, too. I'm
> told, for example, that in Germany the official holiday system takes
> note of a person's religion: A day that is a business day for Catholics
> may be a holiday for Protestants or Jews, and vice versa.

I stand corrected.

I still believe that the correct approach is:

#Find the rules for your country and implement them.

just for the relevant entity instead of the country.

I will expect most places to have algorithmic rules for
holidays that can be implemented.

"the Monday closest to April 19" is certainly something that
can be found for any year.

Arne


From: Lew on 9 May 2010 12:53
Arne Vajhøj wrote:
> I will expect most places to have algorithmic rules for
> holidays that can be implemented.

Good Friday.

The algorithms are horrid. Lookups are simple and straightforward, and easily
extended to handle multiple jurisdictions simultaneously.

--
Lew
From: Arne Vajhøj on 9 May 2010 13:00
On 09-05-2010 12:53, Lew wrote:
> Arne Vajhøj wrote:
>> I will expect most places to have algorithmic rules for
>> holidays that can be implemented.
>
> Good Friday.
>
> The algorithms are horrid. Lookups are simple and straightforward,

You get simple code at the cost of a maintenance problem.

> and
> easily extended to handle multiple jurisdictions simultaneously.

I can't see a problem with extending the algorithmic approach to
handle multiple jurisdictions.

Arne
From: Lew on 9 May 2010 13:41
Arne Vajhøj wrote:
>>> I will expect most places to have algorithmic rules for
>>> holidays that can be implemented.

Lew wrote:
>> Good Friday.
>>
>> The algorithms are horrid. Lookups are simple and straightforward,

Arne Vajhøj wrote:
> You get simple code at the cost of a maintenance problem.

Calling it a "problem" seems rather grandiose. Either way, if the rules
change you have to change something. If you have the rules in a database, you
don't need to recompile and redeploy the application. If you have the rules
in code, that's more of a problem. Then you have to do regression testing,
schedule an upgrade, and all that. Much better to externalize it.

--
Lew
From: Eric Sosman on 9 May 2010 15:50
On 5/9/2010 1:41 PM, Lew wrote:
> Arne Vajhøj wrote:
>>>> I will expect most places to have algorithmic rules for
>>>> holidays that can be implemented.
>
> Lew wrote:
>>> Good Friday.
>>>
>>> The algorithms are horrid. Lookups are simple and straightforward,
>
> Arne Vajhøj wrote:
>> You get simple code at the cost of a maintenance problem.
>
> Calling it a "problem" seems rather grandiose. Either way, if the rules
> change you have to change something. If you have the rules in a
> database, you don't need to recompile and redeploy the application. If
> you have the rules in code, that's more of a problem. Then you have to
> do regression testing, schedule an upgrade, and all that. Much better to
> externalize it.

To look at it another way, why not use the same solution for
holidays as is used for the start and end dates of summer time
adjustments (where observed)? They, too, are region-dependent,
subject to legislative interference, and not easy to predict more
than a year or so in advance. (Remember the trouble that ensued a
few years ago when the USA rules changed? Older Java versions had
the old rules hard-wired in code and were difficult to deal with;
newer versions used tables and were updated easily.)

--
Eric Sosman
esosman(a)ieee-dot-org.invalid
First  |  Prev  | 
Pages: 1 2
Prev: configure Spring to use jax-ws endpoint to consume XML then produce JSON
Next: Reading from very large file