how to make dates without timezones?

[Dr J R Stockton]

In comp.lang.java.programmer message <npr2q495jqbk3u8q02ishlutlcltbv27ij
@4ax.com>, Sun, 22 Feb 2009 07:32:37, Roedy Green <see_website@mindprod.
com.invalid> posted:

To generate proper displays on the server, you need to know each
user's preferred timezone. To generate proper displays is an Applet
of JWS app on the client, just use the default timezone.

Not necessarily.

Wikipedia says
Arnold Schwarzenegger
Born July 30, 1947 (age 61)
Thal, Styria, Austria
and had he remained in Austria his birthdays would have been celebrated
during intervals a multiple of 24 "GMT" hours later (ignoring possible
Summer Time variations).

He now presumably, in California, celebrates nine hours later than that.

When he is 64, he will consider his age to be 64*365.25 days (though
he's probably smart enough to remember the extra hours).


For some purposes one needs a duration in true time; for others one
needs it in apparent time, as defined by the number and fraction of
local civil noons passed (with date-line correction if needed).


That means either using a scale based on civil daycount; or using a
real-time scale and a zero offset from GMT.


One of your pages includes
"In GregorianCalendar, Months are numbered starting at January=0, rather
than 1 as everyone else on the planet does. Yet days start at 1 as do
days of the week with Sunday=1, Monday=2,… Saturday=7."

That could be taken as implying that Sunday=1 is as standard a
numbering, planet-wide, as January=1. As you know, the international
standard numbering has Monday=1, Sunday=7; and your neighbours consider
"international" as meaning "not US".

Glossary, UTC : Replacing "Britain" by "British Isles" would be an
improvement - they are different.

 

[Lew]

It *was* specifically designed to do that. All of those methods are
deprecated now because it was ill-advised. Date.toString still formats

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.

the time based on the current time zone. As I pointed out in an earlier
post, that is not the preferred way to format a time string from Date.

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

But for many of us concerned with localized time, it is acceptable
behavior for debugging.

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.

... Date contains a long, which is a time
zone-agnostic representation of an instant in time. If you use the
deprecated methods, you *might* get a time-zone aware result. The fact
that those methods exist indicates that the original designers *were*

past tense

interested in localizing time with this class. The fact that they are
new deprecated indicates that they decided that it was an ill-advised
effort, and they moved to a more preferred implementation. I think the
OP's confusion is due to this duality, and perhaps unawareness of what
"deprecated" means, or even that the methods are deprecated at all.

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.

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 think the OP is more interested in recording, e.g., a birth date,
which is normally not localized. If my birth date is 03/27/56 3:25PM in
Woodland Hills, CA, that does not imply that it should be localized for
New Zealand, which might put it on a different day entirely. The OP

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.

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.

mentioned that he was initializing Date with month/day/year, which is a
deprecated constructor. I pointed out that this constructor will create
a Date that contains a long representing that month/day/year *at local
server time*. At this point, the long time representation in Date most
likely *does not* represent the desired month/day/year as represented in
the database, as desired by the OP, and using the deprecated methods, or
Date.toString, in different time zones, will cause the date to jump
around wildly.

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.

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.

 

[Arne Vajhøj]

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.)

SQL99 and later

Arne

 

[Lew]

SQL99 and later

There is little reason to use an RDBMS that doesn't have that type.

If it is truly necessary, one still can get correct results with the right care.

 

[Arne Vajhøj]

There is little reason to use an RDBMS that doesn't have that type.

Are there any databases except Oracle and PostgreSQL that
support it ?

Arne

 

[Lew]

Are there any databases except Oracle and PostgreSQL that
support it ?

You left out my statement:

If it is truly necessary, one still can get correct results with the right care.

If one is using a DBMS that doesn't have that type, then take the right care.

 

[Arne Vajhøj]

You left out my statement:

If one is using a DBMS that doesn't have that type, then take the right
care.

That part is not particular relevant for whether there are no reason
to use other databases than Oracle/PostgreSQL.

Arne

 

[Arne Vajhøj]

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

To the OP: It is what it is. Even the new date/time classes slated
for Java 7 will require management. There is no way around the fact
that times have to be managed for timezones; that's the problem
domain. I know you feel that
"java [sic] is dropping the ball on this one", but even if that were
true (and I disagree with you on that) you still have to deal with it.
In point of fact, it's not Java but the computers themselves having
different timezones that is the issue.

... but the real world having different timezones ...

It is not in essence a matter of different timezones, but if different
offsets from UTC.

The problem would still exist if all land other than that directly south
of Denmark were to be eliminated, as long as part of the mini-continent
had Summer Time and part did not.

Yes - one end being in DST and the other end not being in DST would have
the same effect as them being in different timezones.

Arne

 

[Lew]

That part is not particular relevant for whether there are no reason
to use other databases than Oracle/PostgreSQL.

You are right.

 

[John B. Matthews]

Karl Uppiano wrote: [...]

The OP mentioned that he was initializing Date with month/day/year,
which is a deprecated constructor. I pointed out that this
constructor will create a Date that contains a long representing
that month/day/year *at local server time*. At this point, the long
time representation in Date most likely *does not* represent the
desired month/day/year as represented in the database, as desired
by the OP, and using the deprecated methods, or Date.toString, in
different time zones, will cause the date to jump around wildly.

AIUI, even those deprecated constructors and setters adjust the
'long' value to UTC for storage in the Date object. [...] The
constructor creates a Date that contains a long representing the
month/day/year at UTC.

[...]

Ah, the relevant Date constructors and methods adjust for the local time
zone, but don't offer an output format other than local or GMT. For
chronological dates, the OP could standardize on midnight UTC, always
using that format for output. Of course, Calendar & DateFormat should be
preferred to the deprecated methods of Date:

<code>
import java.text.DateFormat;
import java.text.SimpleDateFormat;
import java.util.Calendar;
import java.util.Date;
import java.util.TimeZone;

public class Date2 {

private static final String s = "EEE MMM dd yyyy HH:mm:ss z";
private static final TimeZone z = TimeZone.getTimeZone("UTC");
private static final DateFormat f = new SimpleDateFormat(s);
static { f.setTimeZone(z); }

@SuppressWarnings("deprecation")
public static void main(String[] args) {
Date elvis = new Date(35, 0, 8);
int offset = TimeZone.getDefault().getRawOffset();
elvis.setTime(elvis.getTime() + offset);
print(elvis);

Calendar king = Calendar.getInstance(z);
king.setTimeInMillis(0);
king.set(1935, 0, 8);
print(king.getTime());
}

private static void print(Date d) {
System.out.println(f.format(d)
+ " " + d.getTime()
+ " " + z.getDisplayName());
}
}
</code>

<console>
Tue Jan 08 1935 00:00:00 UTC -1103932800000 Coordinated Universal Time
Tue Jan 08 1935 00:00:00 UTC -1103932800000 Coordinated Universal Time
</console>

 

[epicwinter]

That part is not particular relevant for whether there are no reason
to use other databases than Oracle/PostgreSQL.

Arne

Agreed, although I think oracle is a waste of money at this point.

But you will also note that both databases have Date types that only
store the month, day, year, not the milliseconds since epoch. So if
all major databases have a Date type that is represented as a month/
date/year without any locale then one would think that java would also
have such a type.

 

[epicwinter]

Lew wrote:
To the OP:  It is what it is.  Even the new date/time classes slated for
Java 7 will require management.  There is no way around the fact that
times have to be managed for timezones; that's the problem domain.  I
know you feel that
"java [sic] is dropping the ball on this one", but even if that were
true (and I disagree with you on that) you still have to deal with it..  
In point of fact, it's not Java but the computers themselves having
different timezones that is the issue.
... but the real world having different timezones ...

Arne- I truly understand what you are saying and I do appreciate all
your responses.  The java time stuff makes perfectly good sense from a
academic point of view.  However in the real world we use dates that are
completely ignorant of timezones and times.  The most obvious example is
the birthdate field.  There are so many applications that require the
birthdate field as a security token or just for demographics
verification and display.  And even though my birthdate might fall on a
different day in the Tanzania time zone, if a program is validating a
birthdate in MM/DD/YYYY and I put in the tanzania timezone date it won't
validate.

In this case, what you're dealing with actually is not a date - it's just
a string, perhaps a structured string, that you're using as a token. Are
you performing any date-related operations on it, like asking how long ago
it was? No. So it's not really a date, and using Date is probably a bad
idea.

Tom by that token when you create a Date type in Postgresql why not
just use a "varchar" instead of "date"?

There are plenty of other examples you could have picked where date
operations do come into it, but i submit that if you think about those,
you'll find that they actually *are* cases where you want
timezone-awareness. Current apps may not deal with them in a
timezone-aware way, but this is a bug, not a feature. For instance, if
your scheduling app knows about deadline dates, then those are timezoned:
the end of the working day on the 24th of February is not the same moment
in Tokyo and San Francisco, or even New York and San Francisco, and you
will screw up if you don't recognise that.

tom

Sure I completely agree that many, probably most dates need to be
timezone aware. But you also must recognize that there is a lot of
dates which are very important such as birthdate where people don't
want to acknowledge time zone, at least from a computing point of view.

 

[Lew]

Sure I completely agree that many, probably most dates need to be
timezone aware. But you also must recognize that there is a lot of
dates which are very important such as birthdate where people don't
want to acknowledge time zone, at least from a computing point of view.

There are many situations where one must account for time zone when dealing
with birth dates. It's not a lock.

Bear in mind that there is a time zone involved with birth dates, too - the
time zone where the person was born.

Irrespective of that, one cannot write a date-time class for general use as
the Java folks did with java.util.Date, java.util.Calendar and
java.text.DateFormat (and subclasses thereof) and avoid doing something about
time zones. They came closest to ignoring time zone with Date, once they
deprecated the bad methods, by having it hold only UTC time and trust the
computer on which the instance is created for the time zone.

If time zones are not part of what you care about, for example with your
example of birth date, you can normalize all times to UTC, thus avoiding all
time zone issues, you can record a relevant time zone with your handling of
the time, or you can use a non-Date class like String or a custom class.
That's it.

You can rant and rail about the API not providing you with what you want for
your particular need, you can use what there is, or you can write your own.
Here's a hint: ranting and railing that things should be different from what
they are will not get your code to work. It's a damn shame the writers of
Java's APIs didn't account for your particular need ahead of time. They
didn't do it for my employers either - and that's damn lucky for me or I'd
have no job as a programmer.

 

[Lew]

Agreed, although I think oracle [sic] is a waste of money at this point.

Not if you find that Oracle Express meets your needs.

Doesn't matter, though, since Postgres most certainly has the capacity to.

But you will also note that both databases have Date types that only
store the month, day, year, not the milliseconds since epoch. So if
all major databases have a Date type that is represented as a month/
date/year without any locale then one would think that java [sic] would also
have such a type.

It does - java.util.Date with the milliseconds set to represent
oh-dark-hundred precisely.

Seriously, man, you have been raving for post after post after post about how
Java's built-in API doesn't do what you want. Just accept what is about what
is and move on with your life.

 

[epicwinter]

There are many situations where one must account for time zone when dealing
with birth dates.  It's not a lock.

Yeah right. Name me one application you have used that when you enter
your birthdate they accept it based on time zone. As an example look
at every banking application these days which uses your birthddate as
a security question. Do you think they would be cool with you putting
in the day after because it corresponds to the current time zone you
are in?

Bear in mind that there is a time zone involved with birth dates, too - the
time zone where the person was born.

Irrespective of that, one cannot write a date-time class for general use as
the Java folks did with java.util.Date, java.util.Calendar and
java.text.DateFormat (and subclasses thereof) and avoid doing something about
time zones.  They came closest to ignoring time zone with Date, once they
deprecated the bad methods, by having it hold only UTC time and trust the
computer on which the instance is created for the time zone.

If time zones are not part of what you care about, for example with your
example of birth date, you can normalize all times to UTC, thus avoiding all
time zone issues, you can record a relevant time zone with your handling of
the time, or you can use a non-Date class like String or a custom class.
That's it.

You can rant and rail about the API not providing you with what you want for
your particular need, you can use what there is, or you can write your own.
Here's a hint: ranting and railing that things should be different from what
they are will not get your code to work.  It's a damn shame the writers of
Java's APIs didn't account for your particular need ahead of time.  They
didn't do it for my employers either - and that's damn lucky for me or I'd
have no job as a programmer.

I am not ranting I just feel like this is a common issue and I am
surprised that there isn't a built in solution or there isn't a common
one that is used. I am hoping rather than having people argue with me
how java.util.Date works you would consider that this is a real issue
and suggest solutions. Not too mention, we have minimized the problem
to just discussing dates that don't require timezones, but when you
are dealing with dates that require timezones you still have a big
issue if you run a client/server app. The server produces all kinds
of data and then sends it back to the client. If the server is not
synced up with the client time zone properly you can end up seeing the
result in the wrong time zone.

I understand that the display data is all relative to formatting.
Tthe idea of using formatting to overcome this is a working solution
but not a good one in my opinion. In a big application it requires
too much maintenance and is not a very pragmatic way to manage the
problem. Unfortunately I haven't yet been able to get any of the
potential solutions I have to work. In my head this is a crosscutting
concern and appears to be a good candidate for AOP. What I wish I
could do is use AOP to intercept and change the result of methods like
TimeZone.getDefault(). In this way I could do all my formatting
adjustments in one fell swoop, rather than trying to manage it in the
million places it comes into play in my code.

 

[Lew]

Yeah right. Name me one application you have used that when you enter
your birthdate they accept it based on time zone. As an example look
at every banking application these days which uses your birthddate as
a security question. Do you think they would be cool with you putting
in the day after because it corresponds to the current time zone you
are in?

Absolutely. First of all, the security questions that banks use are arbitrary
- I never use the real information to answer them. How secure is my mother's
maiden name? Not at all secure, so I lie. Second, they are not using the
birthdate as a date but as a string in that context. Time zones don't matter
to strings.


Please do not quote sigs.

I am not ranting I just feel like this is a common issue and I am
surprised that there isn't a built in solution or there isn't a common
one that is used. I am hoping rather than having people argue with me
how java.util.Date works you would consider that this is a real issue
and suggest solutions. Not too mention, we have minimized the problem

Many have suggested solutions, repeating them several times. Some have even
posted working code. Why don't you try them?

to just discussing dates that don't require timezones, but when you
are dealing with dates that require timezones you still have a big
issue if you run a client/server app. The server produces all kinds
of data and then sends it back to the client. If the server is not
synced up with the client time zone properly you can end up seeing the
result in the wrong time zone.

Yes, that is true. That's why they pay us the big bucks to handle these
situations.

I understand that the display data is all relative to formatting.
Tthe idea of using formatting to overcome this is a working solution
but not a good one in my opinion. In a big application it requires
too much maintenance and is not a very pragmatic way to manage the
problem. Unfortunately I haven't yet been able to get any of the
potential solutions I have to work. In my head this is a crosscutting
concern and appears to be a good candidate for AOP. What I wish I
could do is use AOP to intercept and change the result of methods like
TimeZone.getDefault(). In this way I could do all my formatting
adjustments in one fell swoop, rather than trying to manage it in the
million places it comes into play in my code.

You'd be better off just using a DateFormat tuned to the client's time zone to
handle the conversions. That's why the class exists.

On the one hand you complain that Java failed to provide a solution to your
problem. On the other, you refuse to use the solutions it did provide.

 

[Roedy Green]

For some purposes one needs a duration in true time; for others one
needs it in apparent time, as defined by the number and fraction of
local civil noons passed (with date-line correction if needed).

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

Using Calendar when you don't want the time adds all kinds of
complication.
--
Roedy Green Canadian Mind Products
http://mindprod.com

One path leads to despair and utter hopelessness. The other,
to total extinction. Let us pray we have the wisdom to choose correctly.
~ Woody Allen .

 

[Dr J R Stockton]

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

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.

That merely illustrates that a time is not the same sort of thing as a
date.

In the USA, noon occurs at various times; but those times are all 12:00
locally. Sunday at CCAFS is the same duration as Sunday (of the same
date) at VAFB; but it is not the same interval of real time.

For successful date and time work, one must first acquire a full
understanding of the actual needs, and then seek appropriate methods
extant in the system; if none exist, then one must create substitutes.
It is not sufficient to pick on something that might be right, and hope
that it is.

If one is moderately competent, one can easily create one's own date and
time routines from the common knowledge that every normal schoolchild
used to have - with, for efficiency, a little help from appropriate
references (these days, Wikipedia and its links suffices).

 

[Tom Anderson]

Oh, come off it, Tom. The whole point of John's answer

Was probably correct. But "taken as written, that last sentence is utter
nonsense" was simply untrue, and it was to that, and its tone, that i was
objecting.

tom

 

[Tom Anderson]

Tom by that token when you create a Date type in Postgresql why not just
use a "varchar" instead of "date"?

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.

Sure I completely agree that many, probably most dates need to be
timezone aware. But you also must recognize that there is a lot of
dates which are very important such as birthdate where people don't want
to acknowledge time zone, at least from a computing point of view.

I still think it's fewer than you might think, but yes, i do accept that
they exist.

tom