J
Joshua Cranmer
Out of curiosity, what does this have to do with Java?
Out of curiosity, what does this have to do with Java?
A
Arne Vajhøj
Harold said:
Are you sure English is your native language.
Mention any does not mean mentioning a number but actually
mentioning an instance.
But you say that X indicates A when W. And we have shown you examples
where that was not the case. And you have not been able to show an
example where it is the case.
So there are all indications that your are wrong.
Sure did.
I am sure that Lew also see problems with current Calendar/Date/DateFormat
classes.
I do.
But the problems are not the ones you see.
The problems you see are due to your misunderstandings of requirements
for I18N and you lack of understanding how the classes work.
The JSR people are working on some real problems in those classes.
No. Everyone besides you agrees that the output is 100% deterministic
and fully documented.
Arne
A
Arne Vajhøj
Harold said:
I think that is English.
Arne
A
Arne Vajhøj
Harold said:
Calendar. Read the docs and set all the fields you want set.
I am not. We already have it. Calendar.
Ofcourse it is.
Almost all business has things that happen at a certain weekday, at
a certain day in month etc..
Arne
A
Arne Vajhøj
Harold said:
It is very common to do stuff at certain week day or certain day
of month.
Nonsense.
People pay bills the 1st every month not at X milliseconds interval.
Arne
A
Arne Vajhøj
Harold said:
But this is where you completely have misunderstood calendars.
The date builder you ask for requires calendar info.
The 12th day in the 11th month in the 2008th year is now after
the Gregorian calendar, but completely different times after
other calendars.
I18N was prioritized by Java.
As it was in .NET.
Because it is important for businesses.
Most real world Java apps has web frontends.
And no - it is not the PL that decide to send out bills and add
interests to the account the 1st.
Arne
A
Arne Vajhøj
Harold said:
Your name is not Harold Yarmouth but Paul Derbyshire.
Arne
A
Arne Vajhøj
Harold said:
No. You did not know what a troll was in internet context, so I
told you where to read about it.
Arne
L
Lew
Arne said:
Who doesn't? I certainly do. I am currently right in the middle of them at
work, in fact.
Just to name one - Date should have been immutable.
"Harold Yarmouth" averred:
Indeed the output is entirely deterministic and in accordance with its
documentation.
L
Lew
That misconceived calculation, in fact, was the source of the bugs I'm fixing
- people erroneously calculated intervals of days by multiplying 24 hours
times the number of milliseconds in an hour. Of course, not every calendar
day is 24 hours long, at least not in the U.S., Canada, the U.K. and a host of
other countries, so a couple of times a year this would return the wrong interval.
"Harold"'s proposed interval calculation is wrong. The advantage of Calendar,
in this case GregorianCalendar, for all its flaws, is that it correctly
calculates intervals like "three days after y", rather than by such a naive
and incorrect means.
Or the 15th, or every two weeks, or whatever. Calendar is able to give a
reasonable interpretation to "one month after January 31, 2008", not to be
confused with "30 days after January 31, 2008".
Some years back I worked on a warehouse project where the client billed their
customers according to the number of days their goods were in storage, but
also gave special deals as incentives. The deals were things like, "first
three days free, not including weekends or holidays".
Calendars are messy, human, psychological phenomena, not pristine mathematical
concepts.
- people erroneously calculated intervals of days by multiplying 24 hours
times the number of milliseconds in an hour. Of course, not every calendar
day is 24 hours long, at least not in the U.S., Canada, the U.K. and a host of
other countries, so a couple of times a year this would return the wrong interval.
"Harold"'s proposed interval calculation is wrong. The advantage of Calendar,
in this case GregorianCalendar, for all its flaws, is that it correctly
calculates intervals like "three days after y", rather than by such a naive
and incorrect means.
Or the 15th, or every two weeks, or whatever. Calendar is able to give a
reasonable interpretation to "one month after January 31, 2008", not to be
confused with "30 days after January 31, 2008".
Some years back I worked on a warehouse project where the client billed their
customers according to the number of days their goods were in storage, but
also gave special deals as incentives. The deals were things like, "first
three days free, not including weekends or holidays".
Calendars are messy, human, psychological phenomena, not pristine mathematical
concepts.
L
Lew
Arne said:
George Washington's (*) birthday changed by 11 days during his lifetime when
the U.K. switched to the Gregorian calendar. March 29 was once New Year's Day.
(*) The George Washington who was the ninth person designated "President of
the United States", and first under the U.S. Constitution.
J
John W Kennedy
Lew said:
Well, the eight others were actually designated "President of the United
States in Congress Assembled", and had a job more nearly akin to that of
the Speaker of the House.
H
Harold Yarmouth
Arne said:
My name is Harold Yarmouth.
H
Harold Yarmouth
Arne said:
Yes. This is comp.lang.java.programmer. And contrary to what that name
might seem to suggest, according to its charter it is a newsgroup for
discussing Java programmING, not Java programmERS. So discussing me is
not on topic here, nor is discussing fairy-tales, only discussing Java.
H
Harold Yarmouth
Arne said:
Fascinating. The UI layer can keep track of these things for the user.
Why do you think a deeper layer should be charged with telling the user
when garbage day is in his area or whatever?
If you mean internal functions of the software, like rolling the logs
every Wednesday, it would be rolling the logs every 7*86400*1000ms under
the hood, starting at some particular time value, which during
configuration some user set up to be Wednesdays at 2AM, that being
converted near the UI layer into ms since the epoch and passed down to
the lower layer that actually implements the log-rolling behavior.
If the user lives in Fooblia where they have an eight-day week, the 7 in
the above might actually be a parameter also passed down from the higher
layer.
Nowhere in the above does the lower layer need to deal directly with
localization.
No, not nonsense.
Rent. Other bills tend to come whenever they tend to come.
Regardless, the lower layer only needs to have a payRent() method that
the higher layer calls when appropriate, without needing to know
anything about months or years or how that higher layer determines when
and how often to call it.
Or it may have a BusinessRules object that specifies a
RentPaymentPolicy, with an isRentDue() method that returns true from
time to time, and these objects are passed down from the layer that
knows about calendars and locales. That object internally may use
Calendar, without the business logic that uses the object knowing a
thing about this -- it simply calls isRentDue() every few hours and
payRent() when that returns true.
These architectures have better separation of concerns. Particularly,
the latter is extensible, allowing the application designer to put
whatever is needed into their BusinessRules class, and obviating any
need for Sun to start shoehorning everything but the kitchen sink into
Calendar, such as a locale-dependent isLocalTraditionalRentPaymentDate()
and isLocalThis and isTraditionalThat and so forth.
What mystifies me, besides your brutish attitude, is your apparent
confusion on this score. Either you're terrible at OO design
fundamentals or you've confused the programming-technical meaning of
"business logic" with the colloquial meaning of "business". You seem to
be using "business logic" to mean the sorts of things that would go into
a BusinessRules object and would represent the way a business conducts
its business, rather than to mean the guts of the computer program's
logic at the lower levels where it fiddles with Integers and tweaks
HashMaps, above the I/O (network, DB, disk) layer and below the high-up
layers that deal with localization, the user's input, displaying a UI
and output, and such matters.
D
Dr J R Stockton
Thu said:
No. It changed about five hours later, when 1752-09-02 ended and
1752-09-14 began in certain Colonies. He never came here, and by then
he was long back from Barbados.
March 29th may have been New Year's Day, but March 25th was commonly
used. March 1st would be a better choice, /aliter aequalis/.
M
Mike Schilling
Harold said:
And that's not something most people would admit if they didn't have to.
H
Harold Yarmouth
Lew said:
No. Nothing that I wrote is "misconceived".
If the business rules are in some other form than "x is three days after
y" then multiplying by three won't work, of course, but that was not my
hypothesis.
The general pattern to use here is dependency injection: the business
logic layer gets passed a BusinessRules object that has methods like
isRentDue() and the like that can apply business rules. This object may
be parametrized or polymorphic, may use a Calendar or be picked from a
resource bundle by Locale, the BLL doesn't care so long as it implements
the BusinessRules interface. It gets handed down from on high, from the
layer that knows Locales and such issues, having been told which to use
by the user during installation and configuration.
That's not erroneous. Unless you're thinking business days, or a
specific clock time (when it will jump around if there are DST
transitions). As a rule, though, if some message should go out
approximately every 24 hours, it does not matter if it's at 2 o'clock on
the nose, sometimes 2 and sometimes 3, or even very slowly drifts
backwards or forwards around the clock over time due to leap seconds or
something.
Business rules that require specific times (such as switching
Transmitter K to the stored copy of the next new episode of Lost, say)
obviously need to be implemented by way of some policy object that goes
through to a scheduling system, which may in turn employ Calendar to
keep track of DST. (Or Lost suddenly airs at 8 instead of 9 one day and
six million pissed-off viewers all hit your switchboard at about 9:02
asking where the show went.) Business rules that need to count business
days, or care what day of the week it is or when in the month it is more
generally, likewise need to go through some policy object that can be
configured in perhaps a locale-dependent manner (and always in an
our-particular-business-dependent manner, as a rule). But I never
claimed otherwise.
No, it is not, unless there are additional assumptions (the clock time
rather than the interval needs to be fixed, or it's three business days
rather than just three days later) that I did not assume.
Under the particular hypothesis of "every three days, exact time of day
doesn't matter", 3*86400*1000ms is exactly the right approach. (An
every-three-days emailing for instance.)
Okay, that's it.
I am growing quite weary of this constant harassment by you and Arne. If
you don't like me, can't you filter out my posts? They seem to bother
you, so it might be best for all of us if you did so.
Regardless, your frequent, gratuitous, unnecessary, and noisome jabs and
insults directed at me are inappropriate and off-topic for this newsgroup.
Therefore, I feel entirely justified in writing the following:
Shut up about me. Limit your discussions here to the subject matter of
Java. Or else.
Then use it in the BusinessRules black-box that is passed to the BLL for
it to get "phone bill due date" from.
Actually, if we had really well designed systems, there'd be an API by
which the phone company could directly tell another business's computer
system that the bill was due, and how much it was, and the getPhoneBill
method would simply connect (through a dependency-injected object) to
the phone company's system, log in, access some data there, and return
null or a PhoneBill. Imagine the streamlining! Of course there'd need to
be a way to avoid billing disputes. Use of cryptographic signatures to
sign digital invoices would seem to suffice -- can't repudiate it later,
or fiddle with the amount, and each side's crypto can keep the other
honest in each transaction.
And that is exactly why they belong outside the core logic of a program,
perhaps indirectly consulted by it via a black-box policy object
dependency-injected from above, or simply located in the driver code
that calls the core logic routines that then do the actual work, not
knowing why they are called at these times and not at those, and not
caring either.
H
Harold Yarmouth
Arne said:
I have not.
The date builder I ask for requires a bog-standard Gregorian calendar,
not a localized one, because it is used to turn things like
network-layer timestamps into Dates, and low-layer stuff uses pretty
standardized formats. It's dates, intervals, and timing policies dropped
in by the user (as ordinary input, or as part of the local business
rules configuration) that (arguably!) need a full-blown general Calendar
system. And I'd still warrant that for 99% of major business
applications a bog-standard Gregorian calendar does the job here too.
And how often is a file's time-stamp or something similar encoded in any
other than the Gregorian calendar? The most localization you typically
have to deal with there being time-zones, IF the filesystem is dumb
enough to store dates instead of seconds-since-the-epoch under the hood.
Network timestamps have been standardized: Gregorian calendar; UTC+0000,
or else with the timezone specified in the timestamp (e.g. "Date: Wed,
12 Nov 2008 22:44:10 -0500", from the header of your own news post,
specifies the time zone as UTC-0500).
These do not require a fully-general, polymorphic, localized calendar to
convert into a java.util.Date, only a Gregorian calendar parametrized by
a time zone offset.
Database timestamps and filesystem timestamps may be less standardized
in structure, but I think Julian or Arabic (or God help us Mayan)
calendars are downright rare or just plain do not occur in these either.
Your polymorphic Calendar is only useful at the top layers, not the
bottom. (And putting one in a dependency-injected business-policy object
counts as top layers.)
Which means peripheral java.*/javax.* classes instead of peripheral
third-party classes, no more.
Sure it is. The BLL asks a policy object when to do these things. The
policy object is a dependency injection from the PL, and its specific
implementation is really part of the PL. That is the only sensible
architecture, because the BLL should not be cluttered up with
locale-dependent code or special cases; it should delegate to a policy
object that can be set appropriately at installation/setup time.
This is much the way the AWT code is not shot through with if Windows
then this, if MacOS then that, if X then theother type trichotomies;
instead it punts to a Toolkit object that is a black box to it. The
Toolkit object's exact class is OS-dependent. This means if ever a
fourth system became very popular, like say (on some frosty Friday in
July) BeOS, and they go to support it, they just need to stick a fourth
Toolkit subclass into the system and some code to detect a BeOS host
environment on startup and pick that subclass, instead of do a search
for every trichotomy of the sort mentioned above in the AWT code and add
BeOS code at each spot (making them quadrachotomies, or whatever it
should be called). This makes adding support for more host GUIs much
easier -- easy enough there probably already is BeOS support and a bunch
of even more obscure ones and probably wouldn't be if they hadn't done
everything through a Toolkit object.
Likewise the BLL should be parametrized by an object that determines
anything tricky, locale-dependent, dependent on local business rules,
and the like. That's a lot more than "which days are Tuesdays, which are
weekends" and the like that Calendar can answer, by the way -- it tends
to depend on local business rules, tax laws, sometimes even what
specific clients and partners and suppliers a business has. Such an
object is a virtual necessity if the software is not custom-made for one
business, and a wise idea even if it is (the business may move, the
business environment may change, the business may expand into a chain
that has branches in multiple environments). This object will be a
configuration parameter, so passed down from the PL. And this object,
needed *anyway*, is then the natural place to put any code that calls on
Calendar in deciding when to pay what bill and so forth. That is, why have
if (businessPolicy.isRentDueOnFirstOfMonth()) {
if (calendar.get(DAY_OF_MONTH) == 1) {
payRent();
}
}
when we can have
if (businessPolicy.isRentDue()) {
payRent();
}
H
Harold Yarmouth
Lew said:
Dusty history. Nobody has files, database entries, or network packets
timestamped around the time of George Washington's birthday.
Any dates in that kind of time frame are going to be user input to
historical or genealogical software of some sort. Which puts the
responsibility for coping with the non-Gregorian calendar and the change
of calendars squarely in or near the UI layer here, too.