how to make dates without timezones?

[epicwinter]

If you're using it as a security token, i might well do exactly that.
Indeed, since there are several security questions, i'd probably want to
keep them all in one table, and would thus store all of them as varchars,
with a column VARCHAR(40) sq_question and a VARCHAR(40) sq_answer.

If you're using it to do date calculations, then store it as a DATE or
whatever - but then you're very likely to need a timezone attached to it.

Your example of birthdays is an interesting one, though. It's possible to
argue that birth dates are timezoned, but i would agree that they're
pretty much universally used without reference to timezones: this is an
example of a date which doesn't have a timezone attached. Can you think of
any others? Someone suggested the date of easter, and then i suppose
holidays and so on - Canada Day starts earlier in Newfoundland than
British Columbia, because it isn't timezoned.

So we got birthdate, holidays. Next what about order dates? Often
when you call in customer service they ask for your order date. If
you happen to be calling from australia today do you think they will
be able to find your order if they enter the order date in australia
time? I deal with a lot of bank EFTs, they have effective dates.
Again, the bank doesn't not communicate more than month/date/year and
if they do a search in their system that is all they use, time zones
mean nothing. I work in the health care industry and every health
care charge in the united states has a service date. Medicare/
Medicaid don't care about the time or time zone, that date is all they
care about. Insurance Policies have effective dates and expiration
dates and again I can assure you they aren't time zone aware.
Authorization dates are not time zone aware, etc.

Now the question you and others have raised is should these dates then
just be stored as strings? I say no. They are still dates. They
aren't a simple string, they are an Object with 3 components month,
day, year. It is advantageous to be able to read them in and output
them in multiple formats, January 1st, 2009 or 01/01/2009 or
2009-01-01. They still need an equals and comparator that allows them
to be compared as if they are dates not strings.

 

[John B. Matthews]

[...]

I work in the health care industry and every health care charge in
the united states has a service date. Medicare/ Medicaid don't care
about the time or time zone, that date is all they care about.
Insurance Policies have effective dates and expiration dates and
again I can assure you they aren't time zone aware. Authorization
dates are not time zone aware, etc.

The problem is compounded for chronological dates with varying degrees
of uncertainty, as found in a clinical history. "Winter of '02, or maybe
'03" does not admit an easy, natural order.

Now the question you and others have raised is should these dates
then just be stored as strings? I say no. They are still dates.
They aren't a simple string, they are an Object with 3 components
month, day, year. It is advantageous to be able to read them in and
output them in multiple formats, January 1st, 2009 or 01/01/2009 or
2009-01-01. They still need an equals and comparator that allows
them to be compared as if they are dates not strings.

[...]

Indeed, Roedy's trans-diluvian BigDate implements Comparable:

<http://mindprod.com/jgloss/bigdate.html>

For a less ambitious range, the midnight UTC scheme allows one to co-opt
existing parsing and formatting functionality.

In any case, proper encapsulation should render the internals opaque.

 

[Karl Uppiano]

The problem with emphasizing what it used to do incorrectly is that it
misleads people into thinking it still does that. Date no longer has the
design purpose of using the local time zone. I guess my confusion over
your post stemmed from the lack of clarity that the comment was of only
historical significance. Given that adjustment, I see your point.

Sloppy writing. Point taken.

In very few cases is 'toString()' designed for use with real applications.


Exactly. The purpose of 'toString()' is to give a rough-and-ready
identification of an object. One should always think long and carefully
before using 'toString()' for any other purpose than that for which it is
(present tense) designed.


past tense


Several posts in this thread have mentioned that all but the most basic
methods of Date are deprecated. The OP did not ask what that meant, so I
think you are being a bit harsh to assume they don't know.

I did not intend any disrespect, but when I came to the full realization
that the OP was using deprecated constructors to create a Date instance, and
was then complaining about its behavior, the only logical conclusion I could
draw was that they did not fully grasp the meaning of "deprecated", or they
were not aware that the methods were deprecated. One last possibility that
didn't occur to me at the time, might be that they are using some API that
creates a Date for them, using the deprecated API. That could be tough to
troubleshoot.

If a person doesn't know what "deprecated" means for Java, they have a bit
more studying to do before they are ready to take a paycheck for
programming in it.

I agree, but I didn't suggest that. Sometimes a person can just have a blind
spot. If they were never hit full force with a deprecated bug, they might
not take "deprecated" seriously. In some cases, or even many cases, that
could be a benign oversight.

It sure doesn't imply that it shouldn't be. When one mentions their birth
date, it is always implicitly localized to their place of birth. If that
assumption is not accounted for, then one makes the same mistake the
original designers of the Date class made, and we see now what an
egregious error that was.

That was my point exactly. Most people who have my DOB *do not have the
locale*. In that case, they have insufficient information to convert it to a
Date.

Saying that people ignore localization, as you and the OP have done, does
not mean that it is correct to do so. In fact, my birth date, localized
to the U.S. Eastern time zone where I was born, is a day earlier than
people in New Zealand were using at that exact moment. If one were
talking about what was going on in New Zealand at the moment of my birth,
one most definitely would have to localize the time for that zone.

My whole point was that people ignore localization at their peril. By no
means did I mean to imply that it was OK.

AIUI, even those deprecated constructors and setters adjust the 'long'
value to UTC for storage in the Date object. So your statement here is
not correct. The constructor creates a Date that contains a long
representing the month/day/year at UTC.

I would have to test that. I do not believe they changed the original
behavior of the deprecated methods, which IIRC, used the default locale/time
zone to initialize the internal representation as a long *normalized to
UTC*. Furthermore, any of the other deprecated methods, and toString, IIRC,
use the default locale/time zone to reconstitute Date as a string, which
would *not* be the original month/day/year values in other time zones --
precisely the problem the OP is describing.

If that Date does not represent the "desired month/day/year as represented
in the database", it is because the OP was not being responsible for time
zones.

Anyone that messes with dates must be responsible for time zones. That's
why SQL supports the type TIMESTAMP WITH TIME ZONE. (And the OP would be
well advised to use the WITH TIME ZONE types.) Failure to be responsible
for time zones has caused major bugs on many systems for which I've been a
developer.

Endorsing the notion that one can ignore time zones is to endorse the
notion that such bugs are acceptable.

I agree violently. I hope you did not get that impression from my original
remarks, or my writing *really* must suck.

I should re-iterate, that most people who have my DOB have no idea where I
was born, so converting a DOB to a Date really is inappropriate. It is more
correctly just another factor of my identification (e.g., name, address,
DOB). As such, it has about as much relevance to time as my signature has.
If we were to insist on converting DOB-without-time-zone to a time, then we
really need another type, TIMESTAMP WITHOUT TIME ZONE, and Date would have
to carry a flag to indicate no locale/time zone for later formatting
purposes.

Incidentally, a time zone offset alone is insufficient for proper time
localization. You need a locale, because some locales have different
policies for things like daylight saving time. Furthermore, it is possible
that ones birthplace did not observe DST on their DOB. For that matter, we
might have been in a different time zone (if government moved the boundary),
or even using a different calendar. For that reason, historical dates might
better be retained as strings, and never be converted to Date objects, even
if they appear to have some of the characteristics of a date. It is unlikely
that locale databases are completely correct, even for recent dates, and
much less likely that they are correct for all places and times. Using Date
for historical data could cause errors insidiously to creep in.

 

[Lew]

I agree violently. I hope you did not get that impression from my original
remarks, or my writing *really* must suck.

I am not disagreeing with you; I intend to accentuate certain points
that you've made. I agree with the bulk if not all of what you said.

If we were to insist on converting DOB-without-time-zone to a time, then we
really need another type, TIMESTAMP WITHOUT TIME ZONE, and Date would have

<http://www.postgresql.org/docs/8.3/interactive/datatype-
datetime.html>
Table 8-9, first (non-header) row.

to carry a flag to indicate no locale/time zone for later formatting
purposes.

Incidentally, a time zone offset alone is insufficient for proper time
localization. You need a locale, because some locales have different
policies for things like daylight saving time. Furthermore, it is possible
that ones birthplace did not observe DST on their DOB. For that matter, we
might have been in a different time zone (if government moved the boundary),
or even using a different calendar. For that reason, historical dates might
better be retained as strings, and never be converted to Date objects, even
if they appear to have some of the characteristics of a date. It is unlikely

These are excellent points. For example, Southern Indiana in the U.S.
used to not observe DST, but now they do.

that locale databases are completely correct, even for recent dates, and
much less likely that they are correct for all places and times. Using Date
for historical data could cause errors insidiously to creep in.

Even without computers, matching dates and times is a dicey business.
This motivates my responses that suggest that one not seek to be "time-
zone ignorant", more precisely, not seek to be locale ignorant when
manipulating dates and times.

I've been on projects where failure to account for Daylight Saving
Time transitions led to erroneous results. When it is for something
like when you are permitted or required to file a form with legal
significance, an hour can make a huge difference.

 

[Dr J R Stockton]

In comp.lang.java.programmer message <o4e4q4dhehf7ngh4ifva3g1dnj8okpdv3i
@4ax.com>, Sun, 22 Feb 2009 21:48:58, Roedy Green <see_website@mindprod.
com.invalid> posted:

For that I use BigDate which is a pure date with no time/timezone.
See http://mindprod.com/jgloss/bigdate.html

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" !

The Leap Year Rule did not change in 1600; the Pope changed it with
effect from late 1582, the Calendar Act with effect from late 1752.
Vancouver never, I think, changed.

BigDate might be faulty for Alaska : from my critdate.htm :

# 1867/10/06 Fri - Julian, CMJD 3257
# 1867 10 !! --- - Probable position of Alaskan date hiccup; the
previous and following entries were consecutive local days
# 1867-10-18 Fri - Gregorian, CMJD 3257

Chronology is upset when the Date Line moves across a place.


I suppose BigDate stores an integer, MJD-40587.
MJD 40587 = 1970-01-01 GMT = JavaScript day 0.

Why limit to 6-digit years? That's not even enough for the Gregorian
Easter Cycle to repeat. With a 64-bit daycount, you can date the Big
Bang.

 

[Nigel Wade]

So we got birthdate, holidays. Next what about order dates? Often
when you call in customer service they ask for your order date. If
you happen to be calling from australia today do you think they will
be able to find your order if they enter the order date in australia
time?

If they can't their system is broken. It's broken because they have tried to
ignore timezones. Those problems arise exactly because they are trying to
pretend timezones don't exist when they do, and they are absolutely relevant.

A date without a timezone covers a time span of 48hrs, not 24hrs. Or, more
correctly, it is a 24hr period within 48hr window, but the specific 24hrs
within that 48hr window is not determined.

I deal with a lot of bank EFTs, they have effective dates.
Again, the bank doesn't not communicate more than month/date/year and
if they do a search in their system that is all they use, time zones
mean nothing. I work in the health care industry and every health
care charge in the united states has a service date. Medicare/
Medicaid don't care about the time or time zone, that date is all they
care about.

Well, they should. Let's say a patient goes into hospital around midnight. In
the timezone where the patient is located it's one date, in the timzeone where
Medicaid's HQ is located it is a different date. Which date are you going to
record, and why?

Insurance Policies have effective dates and expiration
dates and again I can assure you they aren't time zone aware.
Authorization dates are not time zone aware, etc.

So, let's say you have an insurance policy from a US insurance company which
expires at midnight, 28th Feb. You are on holiday in Australia where it's the
1st March, but in the US it's still the 28th Feb. Is your policy valid or not?
If you need to make a claim will your insurers pay out? Timezones are
absolutely relevant.

Now the question you and others have raised is should these dates then
just be stored as strings? I say no. They are still dates.

Without timezones they are nothing more than markers, with limited relevant
information. In which timezone do they represent the date? The timezone where
the date was entered into the database, the timezone where the transaction
occurred, the timezone where the client happens to be now?

Confused? You deserve to be.
Want to remove the confusion? Use timezones.

If a timezone is not stated explicitly along with a date then one is being
assumed implicitly, whether that is actually understood or not. It's much
better to state it upfront so there is no confusion.

 

[epicwinter]

If they can't their system is broken. It's broken because they have tried to
ignore timezones. Those problems arise exactly because they are trying to
pretend timezones don't exist when they do, and they are absolutely relevant.

Maybe so but this is the norm.

A date without a timezone covers a time span of 48hrs, not 24hrs. Or, more
correctly, it is a 24hr period within 48hr window, but the specific 24hrs
within that 48hr window is not determined.


Well, they should. Let's say a patient goes into hospital around midnight.. In
the timezone where the patient is located it's one date, in the timzeone where
Medicaid's HQ is located it is a different date. Which date are you going to
record, and why?

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, let's say you have an insurance policy from a US insurance company which
expires at midnight, 28th Feb. You are on holiday in Australia where it's the
1st March, but in the US it's still the 28th Feb. Is your policy valid or not?
If you need to make a claim will your insurers pay out? Timezones are
absolutely relevant.

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.

Without timezones they are nothing more than markers, with limited relevant
information. In which timezone do they represent the date? The timezone where
the date was entered into the database, the timezone where the transaction
occurred, the timezone where the client happens to be now?

Confused? You deserve to be.
Want to remove the confusion? Use timezones.

If a timezone is not stated explicitly along with a date then one is being
assumed implicitly, whether that is actually understood or not. It's much
better to state it upfront so there is no confusion.

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 and so
my software has to reflect that.


Let me ask you this. What is the point of having java.util.Date
anymore? Do you feel like the best practice is to just use
java.util.Calendar?

It seems to me that if you are going to use java.util.Date you might
as well just use a long. 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?

 

[Lew]

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.

Do you mean Medicaid's standard when you say "the national standard"?

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.

That may not matter in the particular example that Nigel gave, but it
does matter for things like tax filings.

For example, if you file electronically in the U.S., you have until
midnight local time (local to the filer) to file your taxes, but the
filing goes to the government's national computers which are, for many
if not most Americans, in a different time zone.

Time zones very definitely do matter.

So even if Nigel's specific example can be shot down, don't generalize
that time zones don't usually matter. There are a plethora of
situations where they do.

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 and so
my software has to reflect that.

That is very wrong. Small segments of what you are pleased to call
"the real world" may choose to be "time zone [sic] ignorant", but that
does not generalize to the whole "real world".

Let me ask you this.  What is the point of having java.util.Date
anymore?  Do you feel like the best practice is to just use
java.util.Calendar?

It seems to me that if you are going to use java.util.Date you might
as well just use a long.  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?

Indeed. Why not? Seems to me that you've received several
recommendations in this thread to that effect. OK, well, not to
abandon Date altogether, perhaps, but to use Calendar and DateFormat
to manage your timezone issues.

 

[epicwinter]

Do you mean Medicaid's standard when you say "the national standard"?

Well all the paper forms and electronic format only allow month, date
and year so it would affect every single american insurance company

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.

That may not matter in the particular example that Nigel gave, but it
does matter for things like tax filings.

For example, if you file electronically in the U.S., you have until
midnight local time (local to the filer) to file your taxes, but the
filing goes to the government's national computers which are, for many
if not most Americans, in a different time zone.

Time zones very definitely do matter.

So even if Nigel's specific example can be shot down, don't generalize
that time zones don't usually matter.  There are a plethora of
situations where they do.

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 and so
my software has to reflect that.

That is very wrong.  Small segments of what you are pleased to call
"the real world" may choose to be "time zone [sic] ignorant", but that
does not generalize to the whole "real world".

I don't disagree one bit, but as programmers we have to program for
the exceptions and while you may see it as a small segment it is
significant enough that it deserves more than a hack fix

Indeed.  Why not?  Seems to me that you've received several
recommendations in this thread to that effect.  OK, well, not to
abandon Date altogether, perhaps, but to use Calendar and DateFormat
to manage your timezone issues.

But in your opinion is there any reason why java shouldn't just
deprecate the entire java.util.date class? The class is based around
the concept of the existence of time zones but doesn't let you set
them,
so what does it do that long doesn't?

 

[Dr J R Stockton]

In comp.lang.java.programmer message <[email protected]>,

A date without a timezone covers a time span of 48hrs, not 24hrs. Or, more
correctly, it is a 24hr period within 48hr window, but the specific 24hrs
within that 48hr window is not determined.

More than 48 hours, in fact; look at a current full Time Zone map or
list.

A date, by convention, covers the interval between local 00:00:00 and
local 24:00:00 (which is 24 hours, plus or minus a half-hour or one
hour, plus or minus a leap second, plus or minus the due allowance for
the net change of time offset in one's journey. For unknown
location(s), the meaning in UTC is uncertain. There is a problem,
readily accessible to circumnavigators, Americans, Australians,
Russians, Victorian-era Alaskans, etc., associated with changing local
date by crossing or being crossed by a time boundary.

So, let's say you have an insurance policy from a US insurance company which
expires at midnight, 28th Feb. You are on holiday in Australia where it's the
1st March, but in the US it's still the 28th Feb. Is your policy valid or not?
If you need to make a claim will your insurers pay out? Timezones are
absolutely relevant.

My Cover Note gives expiry at 0001 hours in the 12th. That should mean
0001 hours local, anywhere. But it's some while since I've driven
outside Britain. so I'm not familiar with current arrangements for
driving outside our time area.


There is a need to support, in principle, three types of date+time :
UTC/GMT, applicable everywhere and referring to a single instant; about
30 different versions of local date+time, used in different regions and
referring to a single instant; and chronological date/time, referring to
the instant corresponding to a particular reading of the local
clock/calendar, whatever the location.

Not forgetting that the Royal Navy Day, till late 1805, was offset from
local mean time by 12 hours; and, up to 1925, astronomers' GMT was
twelve hours from Mean Civil Solar Time at Greenwich, in the opposite
direction.

 

[Tom Anderson]

With a 64-bit daycount, you can date the Big Bang.

Not necessary in my case - i only dated her for six months.

tom

 

[Tom Anderson]

But in your opinion is there any reason why java shouldn't just
deprecate the entire java.util.date class? The class is based around the
concept of the existence of time zones but doesn't let you set them,

I'd say the whole point of Date is to represent moments in time *without*
reference to time zones - if a Date i make here in London and one you make
over there in wherever you are are equal, then they represent the same
moment in time. To me, that's timezone independence. As opposed to C's
struct tm, or the kind of thing you're asking for, which represents a
possible state of a clock, but not a moment in time, at least not without
reference to a timezone.

so what does it do that long doesn't?

It's a long which knows it's a date and not just a number. Not an amazing
selling point, i admit!

tom

 

[Lew]

But in your opinion is there any reason why java [sic] shouldn't just
deprecate the entire java.util.date [sic] class? The class is based around

Do you mean java.util.Date?

My opinion is that there is no reason to have an opinion about whether
Java "should" or "shouldn't" deprecate the class.

the concept of the existence of time zones but doesn't let you set
them,

That is not accurate. It is not "based around the concept of the
existence of time zones", it is designed to normalize to UTC (or
something quite close) based on the local time zone. It is, in
effect, designed to cancel the effect of time zone.

The reason it doesn't let you set time zones is that it is supposed to
be largely time zone ignorant (as you requested at the top). It is
more or less single purpose with respect to time zone - it only
factors out the local time zone. It is not intended to be a complete
time zone solution. Stop trying to make it into something that it
isn't.

You've been told again and again and again and again and again what
the solutions are for this. Calendar and (Simple)DateFormat. Those
give you cmoplete time-zone control. Date is not designed for that.
Stop trying to make it into something that it isn't.

so what does it do that long doesn't?

It adjusts the value to which you set it for your local time zone
automatically, normalizing it to UTC (or something quite close).
'long' doesn't do that.

 

[epicwinter]

I'd say the whole point of Date is to represent moments in time *without*
reference to time zones - if a Date i make here in London and one you make
over there in wherever you are are equal, then they represent the same
moment in time. To me, that's timezone independence. As opposed to C's
struct tm, or the kind of thing you're asking for, which represents a
possible state of a clock, but not a moment in time, at least not without
reference to a timezone.


It's a long which knows it's a date and not just a number. Not an amazing
selling point, i admit!

What i find particularly annoying is that you can call setTimeZone in
a calendar instance or instantiate one using getInstance(YourTimeZone)
but if you call getTime() you get a date in the default time zone not
the one you set.

Seems like a bug to me, i mean what is the point then of having
setTimeZone if you can't get the resulting time in the timezone you
set?

 

[Arne Vajhøj]

But in your opinion is there any reason why java [sic] shouldn't just
deprecate the entire java.util.date [sic] class? The class is based around

Do you mean java.util.Date?

That would be a good guess.

You've been told again and again and again and again and again what
the solutions are for this. Calendar and (Simple)DateFormat. Those
give you cmoplete time-zone control. Date is not designed for that.
Stop trying to make it into something that it isn't.

That is good advice.

That is not accurate. It is not "based around the concept of the
existence of time zones", it is designed to normalize to UTC (or
something quite close) based on the local time zone. It is, in
effect, designed to cancel the effect of time zone.

It adjusts the value to which you set it for your local time zone
automatically, normalizing it to UTC (or something quite close).
'long' doesn't do that.

What normalization are you talking about ?

Both setTime and the constructor that takes a long
just stores the value.

Arne

 

[Arne Vajhøj]

What i find particularly annoying is that you can call setTimeZone in
a calendar instance or instantiate one using getInstance(YourTimeZone)
but if you call getTime() you get a date in the default time zone not
the one you set.

Seems like a bug to me, i mean what is the point then of having
setTimeZone if you can't get the resulting time in the timezone you
set?

No.

You get a Date that represent the real time independently
of timezones.

Arne

 

[Arne Vajhøj]

But in your opinion is there any reason why java shouldn't just
deprecate the entire java.util.date class? The class is based around
the concept of the existence of time zones but doesn't let you set
them,
so what does it do that long doesn't?

I would say that the two main reasons are type safety and
backwards compatibility.

Arne

 

[epicwinter]

No.

You get a Date that represent the real time independently
of timezones.

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.

 

[Arne Vajhøj]

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.

It uses it.

When it converts between the real time (the long) the the timezone
specific components.

It can not use it for getTime() since Date is not timezone specific.

Arne

 

[Mark Space]

There is a need to support, in principle, three types of date+time :
UTC/GMT, applicable everywhere and referring to a single instant; about
30 different versions of local date+time, used in different regions and
referring to a single instant; and chronological date/time, referring to
the instant corresponding to a particular reading of the local
clock/calendar, whatever the location.

I think there may also be statute days/time too. At least in the US,
certain aspects of time are fixed by statute (law) and have nothing
really to do with UTC or any other instant in time. For example, a
statute month is 30 days, regardless of the number of days it actually
has. All legal transactions (for example, prorating rent due or a
mortgage payment) are based on a month of 30 days.

I think this concept is closer to what the OP is talking about. In
accounting, the date is recorded, and its properties mat be set by law,
not by GMT. (Note: I'm not any kind of accounting or financial expert,
just aware of a few things regarding mortgages and such.)