how to make dates without timezones?

[Mark Space]

Urgh! please change "Julian day numbers relative to 1970 Jan 01" to
something more like "a daycount with 1970 Jan 01 being Day 0". One
should never use "Julian day" or "Julian Date" except with the correct
meaning : JD 0.0 = Gregorian BC 4714-11-24 12:00 GMT, thus Chronological
JD = that + 0.5 and measuring local days rather than Greenwich ones,
Modified JD = JD-2400000.5, CMJD is like MJD but local days. "forthe" !

I dunno. It made sense to me. "Julian days" but since 1970, not 4714
B.C. Although the idea (now that I look it up) that Julian days start
at noon (not midnight) is kind of off for a modern reader.

 

[Lew]

Yeah I understand, but you must admit it is extremely misleading. Why

Nonsense. It would be ridiculous to "admit" something so patently false.

add the TimeZone functionality to calendar [sic] if you aren't going to
fully implement it.

Huh?

As far as I can tell, time zones are fully implemented in java.util.Calendar.

 

[blue indigo]

Yeah I understand, but you must admit it is extremely misleading. Why
add the TimeZone functionality to calendar if you aren't going to
fully implement it.

Pardon me, mate, but haven't we already had this flamewar in this
group fairly recently? Back in December or thereabouts.

I think the consensus that emerged was that
a) time zones and other localization must be taken into account in serious
business applications;
b) java.util.Calendar isn't the best-designed class ever; and
c) there's a JSR on the horizon that might provide a much improved one,
even adding much-desired time interval types, but you probably
shouldn't hold your breath.

 

[Nigel Wade]

Maybe so but this is the norm.

and does that mean you have to follow like a sheep?
Why not start to do things correctly, even if that means you have to push
against the tide for a while, and avoid the errors, ambiguities and bugs which
arise from implicit timezones.

The national standard dictates that there are no times or locale in
service dates, so they would record the date at the hospital with no
timezone.

So the timezone is recorded, but implicitly rather than explicitly. Instead of
recording it explicitly as part of the date it's hidden within some other field
which records the details of the hospital. Anyone who needs to interpret the
date correctly has to dig around in the details for the hospital in question to
determine in which timezone it's located. That makes sense...

Again it doesn't matter because united states medical service dates
don't have time zones. So all that matters is if the service date
posted is within the policy effective/expiration date range.

What I am trying to get at is that not using timezones creates ambiguity. Which
service date gets recorded? The date where the claimant is, the date where the
call centre receiving the claim is located, the date where the insurance co. HQ
is located, the date where the claim adjuster assessing the claim is located?

I understand this point of view and don't disagree, but as I have said
the real world chooses to be time zone ignorant at this point

The real world I live in does not ignore timezones.

and so
my software has to reflect that.

Why? Can't you explicitly record the timezone so your software gets it right?
Any date has to be associated with a timezone, it's either implicit or
explicit. All you need to do is make the implicit one explicit.

Let me ask you this. What is the point of having java.util.Date
anymore?

Because it serves a very useful purpose, it is simple and records an instant in
time. Timezones are an artifact of human representation of wall-clock time,
they are not necessary to record the instant of an event.

Do you feel like the best practice is to just use
java.util.Calendar?

If you need wall-clock date/time then you need Calendar which has timezone
information. If all you need is the instant in time then Date is sufficient.

It seems to me that if you are going to use java.util.Date you might
as well just use a long.

It is a long, with bells, which make it more useful.

Anytime you want to display or do something
with a java.util.Date it makes internal calls back to classes like
Calendar/BaseDate/TimeZone to get the default time zone anyway, so why
not just go straight to the source? So why not just always use
Calendar?

You could do, but Calendar is big, cumbersome and unwieldy. If all you need to
do is record, or transport, the instant in time at which an event occurred then
you only need a Date. If you need to interpret, or store, that information in
wall-clock date/time format then you need a Calendar with a timezone.

I think the mistake Sun made with Date, and the now-deprecated methods, is they
tried to combine the two into one class, and to keep it simple they ignored
timezones. This lead to a class which used implicit timezone information to
convert an instant in time to/from a wall-clock time/date. This is not only
ambiguous it is also incorrect as timezones (even implicit ones) have more than
simple hour-offset from GMT/UTC, they also carry the variable DST information.

 

[Patel]

Use SimpleDateFormat, DateFormat like :
DateFormat formatObj = new SimpleDateFormat ("MM/dd/yyyy");
If you don't feel its feasible solution then go for implementing your
own class.