Possible bug in Calendar

J

Joshua Cranmer

Harold said:
When arrogant and megalomaniacal twits more or less come right out and
call themselves "gods" in a bid to be heard, mortals should consign them
to the depths of their killfiles.

Lew was not referring to himself as a "god", but the one who wrote the
linked article (i.e., Joshua Bloch, a key Java developer). I think it is
safe to say that those who wrote Java are better authorities on it than
you or I.
 
A

Arne Vajhøj

Lew said:
Postgres follows the SQL standard wrt to datetime types. Probably the
least compliant RDBMS in this area is Access, followed by MySQL.
MySQL particularly has an idiosyncratic semantic for TIMESTAMP.

MySQL TIMESTAMP semantics are very common. It is just usually
called something else.

Arne
 
H

Harold Yarmouth

Lew said:
Ancient Japanese saying: Only perfect practice makes perfect.

That is either completely irrelevant to this newsgroup's topic, or a
veiled insult AND completely irrelevant to this newsgroup's topic.
Ancd you aren't going to thank him for anything.

That is not your place to decide. Who do you think you are, anyway -- God?

Lew wrote elsewhere in this same thread:
I have ten years' Java experience and my "feel for these things"
is quite different. It also helps that I have authoritative
evidence that 'getX' factories don't necessarily imply singletons.
When the gods speak, mortals should listen.

I'll take that as a "yes".

There's a cell waiting for you at Bellevue, and another one being warmed
up in a different place for after you die, I suspect.
 
A

Arne Vajhøj

Harold said:
Just you stop pestering me and, especially, insinuating in public that
I'm some sort of liar or charlatan.

But making claims and not being able to substantiate them is being
a charlatan !
It is exceptionally rude and
uncalled-for behavior that I shall not tolerate from you or anybody else!

Well - you don't have anything to say in that matter.
(If you insist -- almost ANY ten.)

Names please.

Arne
 
A

Arne Vajhøj

Harold said:
No, there aren't.

There are.
Irrelevant. Nobody much uses pre-industrial calendars anymore, certainly
not for business applications and e-commerce.

There is nothing pre-industrial about those.

And internationalization of business apps are very common.

Arne
 
H

Harold Yarmouth

Arne said:
It has a set method that can set each of them individually and
are what should have been used by Paulmouth.

Please do not misspell my name. It is not that difficult to get right.
And if you have difficulty anyway, copy-paste is just about foolproof. I
use it all the time myself if I run into a complex and long foreign name
-- or one with an accented character that isn't on my keyboard. Hint, hint.
 
H

Harold Yarmouth

Arne said:
I do not see Paulmouth's problem as a problem though.

That's two occurrences of the same rather improbable misspelling. I am
now forced to suspect that you are being intentionally rude to me,
Barney Vajhoj.
 
A

Arne Vajhøj

Harold said:
"Cultural sensitivity" is neither here nor there. "Cultural sensitivity"
is not a major concern of programming language or API design. It may be
a concern of application user-interface design, but that's a whole
different kettle of fish.

Imagine if it were otherwise -- Calendar would not accept dates before
4004 BC, to avoid offending Christians, or after 2012, to avoid
offending Mayans. There'd be something to prevent the coding of genetic
algorithms. SecureRandom and all of the crypto would be missing, since
some cultures strongly frown upon any kind of concealment or disguise of
information, either from people in general or specifically from
government or religious authority. Programs written in Java would refuse
to work on Sundays. The sound, MIDI, and MP3 libraries would refuse to
work when the current locale setting was Afghanistan and the system
clock set prior to around mid-2003. And so forth.

That is the sort of mess we'd have if we took
designing-in-cultural-sensitivity to its logical conclusion.

Nonsense.

You can obviously not compare those two things.

Java enables people to write programs.

Java need to support multiple calendars to support people that
use those calendars.

Java needs to support sound for those that make apps that use
sound.

Java should not limit functionality due to Taleban religious
beliefs or racists that think only the Gregorian Calendar
is needed.

Arne
 
J

Joshua Cranmer

Harold said:
"Cultural sensitivity" is neither here nor there. "Cultural sensitivity"
is not a major concern of programming language or API design. It may be
a concern of application user-interface design, but that's a whole
different kettle of fish.

I was referring to "cultural sensitivity" to be polite in suggesting
"You have an arrogant Anglo-Amerocentric viewpoint." There are countries
who use non-Gregorian calendars for civil purposes, by requiring that
the API dictate everything in Gregorian, you've essentially said "screw
you" to said countries.
Which means using the plain-Jane Gregorian calendar under the hood in
Date and other business objects related to dates, with DateFormat or
other similar classes providing translations into locale-specific
representations.

When viewed pedantically, the typical fiscal calendar is not even the
same as the civil Gregorian calendar in place in most countries: March
1, 2009 is in the same fiscal year as November 2, 2008. So if I'm doing
calculations on a fiscal calendar, it should tell me that the two are in
the same year, right?

Note that time is near-impossible to determine good APIs for since the
human concept of time is not even consistent, let alone the technical
muck designed to make it saner for human use.
 
A

Arne Vajhøj

Harold said:
Do not lie about me in public again. I am not either an asshole or an
ignorant racist.

You are an asshole.

You are ignorant.

You seems to be a racist, but it could be just the ignorance that
gives that impression.
People are free to use their older calendars to schedule religious
ceremonies or whatever. However, such things have no place in core
utility classes in a programming language API; they belong in
localization code affecting input parsing and output display, i.e. in UI
code, rather than the code for business-layer objects, where they belong
in the standard API at all rather than in third-party libraries.

That is not a racist remark either. It is merely an observation of fact.
Localization belongs in the UI layer, not in the business layer. The
alternative is catastrophic: applications that communicate with each
other won't be speaking the same language.

Believing that non Gregorian calendars are older and most suited
for religious purposes is either ignorant or racists.

Your distinction between PL and BLL is irrelevant because noone
has made any distinction between those so far and wrong, because
BLL most certainly can need calendar info.

BTW, it is worth mentioning that the .NET framework includes
several calendars:

EastAsianLunisolarCalendar
GregorianCalendar
HebrewCalendar
HijriCalendar
JapaneseCalendar
JapaneseLunisolarCalendar
JulianCalendar
KoreanCalendar
KoreanLunisolarCalendar
PersianCalendar
TaiwanCalendar
TaiwanLunisolarCalendar
ThaiBuddhistCalendar
UmAlQuraCalendar

They know how important i18n is for business apps.

Arne
 
A

Arne Vajhøj

Harold said:
I can't. It's just the code that's out there. You get a feel for these
things working with, seeing, using, and writing large amounts of code.

You mean that you don't know any examples and that you just made up your
claim and you don't have the character to admit it !

Arne
 
L

Lew

Joshua said:
Lew was not referring to himself as a "god", but the one who wrote the
linked article (i.e., Joshua Bloch, a key Java developer). I think it is
safe to say that those who wrote Java are better authorities on it than
you or I.

Correct. The coincidence of last name is irrelevant to my characterization of
Joshua Bloch as a "god" of Java.
 
A

Arne Vajhøj

Harold said:
I never claimed otherwise. I said no-argument getInstance methods in the
absence of a clear need for a polymorphic return value, which is a far
narrower and more specific set of circumstances.

Well - the last one is something you added later.

(because you have not understood that Calendar indeed has polymorphic
requirements, then you apparently thought it would support your case)

But it is already proven that your rule is not followed in the
Java API and you have not been able to mention any library that
does.

Arne
 
A

Arne Vajhøj

Harold said:
But I never said that getInstance methods return only singletons! I said
that no-argument getInstance methods with no obvious reason to return
polymorphic values tend to indicate a singleton or some other "bound
instance", for example a per-thread instance.

There are 9 no-arg getInstance methods among those 44 - none of those 9
are singletons either.

Arne
 
A

Arne Vajhøj

Harold said:
And the IDEs tend to show the current method documentation (say, for
"set") only.

Which is why all Java developers above the absolute beginners level read
the complete API docs.
I don't see any more need for a factory of date builders than I do for a
factory of StringBuilders. StringBuilder gets by with a straight
constructor.

See my other post about suspecting that they mixed multiple
responsibilities into one class, ending up with a boondoggle for their
efforts.

You are completely missing the point. Using a factory excatly
separate responsibilities.
I never claimed otherwise. I said that in the absence of a strong reason
for the return value to be polymorphic, it tends to indicate a singleton
or otherwise a "bound" instance of some sort.

Which has been proven to be wrong.

Arne
 
A

Arne Vajhøj

Harold said:
My IDE shows me the documentation for the method whose invocation I'm
writing. That would be the set method in this case.

Your mistake !

Arne
 
H

Harold Yarmouth

Eric said:
Here are two things I've observed:

1) Every date/time package I've ever run across in any
programming language has been deficient in one way or another,
sometimes to the point of looking utterly stupid, and

2) Many of those date/time packages were designed and
implemented by people a whole lot smarter than I am.

From these observations, I draw two conclusions:

A) The ways people reckon dates and times are far more
complicated than a naive glance suggests, and

B) It's folly to throw words like "stupid" around. (Or
stupid to throw words like "folly" around; I can never keep
that straight.)

As examples of (A), consider "same time next month" when
uttered on January 30, or "same time next year" when uttered
on February 29. Even "same time tomorrow" will be tricky in
my locale for most of this Saturday.

I can sum up the problem in one quick sentence: failure to separate two
areas of responsibility, "internal representation and arithmetic" and
"UI presentation". The former can be done very cleanly, using either a
standard Gregorian calendar in the UTC+0000 time-zone or just using
seconds since the epoch or whatever. The latter then boils down to
converting between a locale-dependent representation and the internal one.

Systems with such a division can potentially do a very good job of
avoiding Y2K bugs, bugs when the hour gets set back in the fall, and
similar problems. In particular, when internal times are stored in a
fixed time zone, or in seconds since the epoch, the internal clock never
jumps backwards by an hour and no two events have the same timestamp
without being genuinely (close to) simultaneous. Only the display in the
UI is affected by DST transitions and such.

DST transitions end up having either of two interesting UI effects.

One would be for the date/time combos after the transition to be
affected in their presentation, which could result in e.g. an
interactive program listing or appointment-book app showing

11:00 PM 12:00 PM 1:00 AM 1:00 AM 2:00 AM

with different things under the two "1:00 AM" columns. Or something in
the same general vein. Different hours with the same displayed name. If
the user can click to manipulate objects, and not just get a "handle" on
them by typing a name, it won't cause too much trouble.

The other would be to have the presentation of ALL dates switch. A
simple switch-the-system-locale-at-DST-transition system would cause
this, and then the display above would go from 11 until 3, except that
if you did something after the DST transition to make it redraw itself,
it would then show 10 until 2. At neither time would two hours have the
same name, but you could set something to 2 PM the next afternoon in
such an interface and have it change overnight to be at 1 PM, which is
why I'd favor the first method for handling DST over the second.

(The forward transition in the spring would have similar, but milder
effects. In the second case, that 2PM appointment would jump to 3PM,
which is equally bad. In the first case, the displayed hour names would
skip over one name you'd normally expect, rather than duplicate one.
Here is where the effect is milder, because typing in a time around
"spring forward" won't sometimes be ambiguous unlike in the "fall back"
case. But a UI that lets the user click on objects to manipulate them
without having to type in their names does not suffer much from such
ambiguity anyway.)

Date arithmetic would yield simple and predictable results with a proper
separation of content and presentation concerns: adding 30 days, for
example, would move Jan. 30 to Feb. 29 on leap years and Mar. 1
otherwise. If there was an "add one month", it would have to cope
somehow (say, by snapping the day to the last day of the month if it
would otherwise go over) and its behavior at corner cases would have to
be properly documented. (That results in Jan. 30 plus 1 month being
either Feb. 29 or Feb. 28, depending on the leap-year status of the year
of the date being manipulated.)

Often, the application may need a bit of its own localized logic to deal
with figuring out what is the "next business day" or similarly. This
should be cleanly separated from the core Date class that concerns
itself with merely representing dates and times and with "next day" and
similarly.

Possibly, cleanest would be to have seconds (or milliseconds, or
whatever) since the epoch as the core time type's representation and all
notions of months, days, years, or other such be in the presentation
classes rather than the core Time class. One might even then have a Date
class that is polymorphic and localized, and that wraps a Time object.
It could be set from a Time object and its Time object retrieved, as
well as have formatting, parsing, and other methods and methods like
addDays. You'd also want Duration objects, built on an integer, with
DateDifference the localized wrapper. Date subtraction would produce
DateDifference objects, and DateDifferences could be summed or
subtracted, multiplied by scalar integers, and added to or subtracted
from Dates, for any arithmetic involving fixed intervals. Under the
hood, long arithmetic is being performed. Date methods might also exist
to add "n months", "n years", or similarly, that deal with Feb. 29
appropriately, and perhaps even a "nextBusinessDay" method could exist,
given the locale objects were specific and detailed enough to have each
area's local holidays and business practises mapped. Some areas have
Friday and Saturday as the weekend and a Saturday sabbath, for example.
States in the US have civic holidays other states lack.

At least all of the "messy" bits would be swept into a class whose
responsibility was to deal with them and to manage presentation and
user-input of dates, while simple under-the-hood timekeeping would be
managed by something clean and simple.

I think they tried to do something like that with Date/Calendar, but
ended up giving Calendar the job of being Date's primary builder as
well, instead of Date having its own simpler means of constructing it
that a) used the default international standard representations, a
Gregorian calendar in the GMT timezone as I understand it, and b) wasn't
deprecated.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,900
Latest member
Nell636132

Latest Threads

Top