how to make dates without timezones?

[epicwinter]

In my database I have a lot of date fields that aren't time stamps but
just store dates. The problem is that when i load them into a java
Date it automatically assigns the timezone. The result will be a date
with 0 hours, 0 minutes, 0 seconds and the time zone of the server.
Like 02/20/2009 00:00:00 CST.

My application is a client server app using rmi. When the date is
passed to the client through all of the sudden the time zone which was
auto assigned when the date was populated from the server can change
the actual date. So if on the server I have 02/20/2009 00:00:00 CST
and the client is on pacific time then the date shows as the day
before. Because that date in pacific standard time is 02/19/2009
23:00:00 PST

So is there a way for all my dates to be completely ignorant of time
zones?

 

[Lothar Kimmeringer]

So is there a way for all my dates to be completely ignorant of time
zones?

Store them in UTC-time (GMT+0).


Regards, Lothar
--
Lothar Kimmeringer E-Mail: (e-mail address removed)
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!

 

[Arne Vajhøj]

In my database I have a lot of date fields that aren't time stamps but
just store dates. The problem is that when i load them into a java
Date it automatically assigns the timezone. The result will be a date
with 0 hours, 0 minutes, 0 seconds and the time zone of the server.
Like 02/20/2009 00:00:00 CST.

My application is a client server app using rmi. When the date is
passed to the client through all of the sudden the time zone which was
auto assigned when the date was populated from the server can change
the actual date. So if on the server I have 02/20/2009 00:00:00 CST
and the client is on pacific time then the date shows as the day
before. Because that date in pacific standard time is 02/19/2009
23:00:00 PST

So is there a way for all my dates to be completely ignorant of time
zones?

The same time *can* be two different days in two different timezones.

The two most obvious solutions for your requirement to have client
show server date are:
- have the server do the formatting and send String instead of DateTime
- have the client format using the servers timezone

Arne

 

[Arne Vajhøj]

Store them in UTC-time (GMT+0).

He probably already are. It is a formatting issue.

Arne

 

[Mark Space]

The two most obvious solutions for your requirement to have client
show server date are:
- have the server do the formatting and send String instead of DateTime
- have the client format using the servers timezone

For the latter, just always using UTC for formatting on the client and
server should do the same thing, as Lothar suggested.

Option 3:

class MyDateWithOutTimeZones {
int day;
int month;
int year;
}

This is basically the same idea as formating the date on the server as a
string and sending that to the client. However, as a general rule, one
shouldn't encode multiple data into a single string, so thinking about
the date as three discreet pieces of data might be a tad more
maintainable in the long run. (Three separate strings would probably
work just as well as three ints.)

 

[epicwinter]

Store them in UTC-time (GMT+0).

Regards, Lothar
--
Lothar Kimmeringer                E-Mail: (e-mail address removed)
               PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
                 questions!

This doesn't help, even though they are at UTC on the server they
still adjusts to the client's timezone when they are remoted over

 

[epicwinter]

The same time *can* be two different days in two different timezones.

The two most obvious solutions for your requirement to have client
show server date are:
- have the server do the formatting and send String instead of DateTime

This would work but I was really hoping to avoid it, it is a pain to
maintain and just kind of kludgy. It seems to me that java should
have a date class without time and timezone. Every database has a
date type and a timestamp type, yet java doesn't support just date
types. What surprises me more is that this doesn't appear to be a
common issue.

- have the client format using the servers timezone

I have tried this too. It works in some respects but creates new
issues. There are a few areas where time is pertinent on my
application and in this manner it would always show the client the
wrong time unless they happened to actually be in the same time zone
as the server.

 

[Mark Space]

I have tried this too. It works in some respects but creates new
issues. There are a few areas where time is pertinent on my
application and in this manner it would always show the client the
wrong time unless they happened to actually be in the same time zone
as the server.

This implies to me that you have two different types of dates, and you
shouldn't be trying to use the same type (java.util.Date) for both.
Break one or the other out into a separate class so you can deal with
its idiosyncrasies separately. I would also not use a subclass of
java.util.Date.


String probably is the wrong type for the second type of date. Make a
class, with a unique format on the wire, so that you don't accidentally
get the the two mixed up.

 

[Arne Vajhøj]

This would work but I was really hoping to avoid it, it is a pain to
maintain and just kind of kludgy. It seems to me that java should
have a date class without time and timezone. Every database has a
date type and a timestamp type, yet java doesn't support just date
types. What surprises me more is that this doesn't appear to be a
common issue.

None of the classes java.util.Date, java.sql.Date etc. has
timezone - they basically contains number of milliseconds since
1-Jan-1970 00:00:00 in London.

It is all in the formatting !

I have tried this too. It works in some respects but creates new
issues. There are a few areas where time is pertinent on my
application and in this manner it would always show the client the
wrong time unless they happened to actually be in the same time zone
as the server.

I don't understand that argument.

You can specify timezone for each individual formatting (DateFormat
has a setTimeZone method.

Arne

 

[Arne Vajhøj]

For the latter, just always using UTC for formatting on the client and
server should do the same thing, as Lothar suggested.

I think Lothar suggested saving in UTC. Which Java already does.

If the client format in the same time as server, then there are no
problem no matter what timezone that is.

But I think server timezone will create less confusion than
GMT/UTC.

Option 3:

class MyDateWithOutTimeZones {
int day;
int month;
int year;
}

This is basically the same idea as formating the date on the server as a
string and sending that to the client. However, as a general rule, one
shouldn't encode multiple data into a single string, so thinking about
the date as three discreet pieces of data might be a tad more
maintainable in the long run. (Three separate strings would probably
work just as well as three ints.)

But if it is only to be displayed, then String is fine - and if it
is to be manipulated, then Date is what the manipulation methods
expect - so I can not really see what this offers.

Arne

 

[John B. Matthews]

None of the classes java.util.Date, java.sql.Date etc. has
timezone - they basically contains number of milliseconds since
1-Jan-1970 00:00:00 in London.

It is all in the formatting!

Yes! For example,

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

public class Date1 {

private static final String s = "EEE MMM dd HH:mm:ss z yyyy";
private static final DateFormat f = new SimpleDateFormat(s);

public static void main(String[] args) {
Date now = new Date();
print("US/Eastern", now);
print("Europe/London", now);
print("Europe/Copenhagen", now);
print("Australia/Sydney", now);
}

private static void print(String tz, Date d) {
f.setTimeZone(TimeZone.getTimeZone(tz));
System.out.println(f.format(d)
+ " " + d.getTime()
+ " " + tz);
}
}
</code>

<console>
Sat Feb 21 14:47:28 EST 2009 1235245648606 US/Eastern
Sat Feb 21 19:47:28 GMT 2009 1235245648606 Europe/London
Sat Feb 21 20:47:28 CET 2009 1235245648606 Europe/Copenhagen
Sun Feb 22 06:47:28 EST 2009 1235245648606 Australia/Sydney
</console>

 

[Arne Vajhøj]

This implies to me that you have two different types of dates, and you
shouldn't be trying to use the same type (java.util.Date) for both.
Break one or the other out into a separate class so you can deal with
its idiosyncrasies separately.

But why ?

I would prefer to have the app decide whether to format a given time
according to local time or UTC over having that information embedded
in the time itself.

Arne

 

[epicwinter]

This implies to me that you have two different types of dates, and you
shouldn't be trying to use the same type (java.util.Date) for both.
Break one or the other out into a separate class so you can deal with
its idiosyncrasies separately.  I would also not use a subclass of
java.util.Date.

String probably is the wrong type for the second type of date.  Make a
class, with a unique format on the wire, so that you don't accidentally
get the the two mixed up.

Yes, I deal with dates as in month, day, year and timestamp as in
month, day, year, hour, min, second.
This is exactly my problem, I do use java.util.Date for both. It
seems to me that there should be a strictly CalendarDate class i could
use for the date types and CalendarTimeStamp class for the timestamp
types

 

[epicwinter]

None of the classes java.util.Date, java.sql.Date etc. has
timezone - they basically contains number of milliseconds since
1-Jan-1970 00:00:00 in London.

It is all in the formatting !



I don't understand that argument.

You can specify timezone for each individual formatting (DateFormat
has a setTimeZone method.

Arne

Arne- I am sorry but I don't understand what you mean by it is just
formatting. In my database i only store a date type that includes
month, day, year. When I load that into a Date class it automatically
assigns the local timezone and i get 02-21-2009 00:00:00 CST or
whatever the time zone is. If that date is then viewed on a client on
PST then it is 02-20-2009 22:00:00 PST. So the date portion shows the
day before.

 

[epicwinter]

None of the classes java.util.Date, java.sql.Date etc. has
timezone - they basically contains number of milliseconds since
1-Jan-1970 00:00:00 in London.

It is all in the formatting!

Yes! For example,

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

public class Date1 {

    private static final String s = "EEE MMM dd HH:mm:ss z yyyy";
    private static final DateFormat f = new SimpleDateFormat(s);

    public static void main(String[] args) {
        Date now = new Date();
        print("US/Eastern", now);
        print("Europe/London", now);
        print("Europe/Copenhagen", now);
        print("Australia/Sydney", now);
    }

    private static void print(String tz, Date d) {
        f.setTimeZone(TimeZone.getTimeZone(tz));
        System.out.println(f.format(d)
            + " " + d.getTime()
            + " " + tz);
    }}

</code>

<console>
Sat Feb 21 14:47:28 EST 2009 1235245648606 US/Eastern
Sat Feb 21 19:47:28 GMT 2009 1235245648606 Europe/London
Sat Feb 21 20:47:28 CET 2009 1235245648606 Europe/Copenhagen
Sun Feb 22 06:47:28 EST 2009 1235245648606 Australia/Sydney
</console>

The problem is I want it to print the same date no matter what the
timezone. I am just trying to deal with the date portion and I don't
understand why java doesn't have a Date only date/time class.

 

[Arne Vajhøj]

Yes, I deal with dates as in month, day, year and timestamp as in
month, day, year, hour, min, second.
This is exactly my problem, I do use java.util.Date for both. It
seems to me that there should be a strictly CalendarDate class i could
use for the date types and CalendarTimeStamp class for the timestamp
types

To get a real Date class you will have to either:
- use java.sql.Date
- use your own class
- wait for Java 1.7 which I assume will have such a beast

Arne

 

[Lew]

This doesn't help, even though they are at UTC on the server they
still adjusts to the client's timezone when they are remoted over

Look at java.util.Calendar and java.text.DateFormat.

A Date is just a thin wrapper around a long. It doesn't contain timezone
information.

 

[Arne Vajhøj]

epicwinter wrote:
epicwinter wrote:
In my database I have a lot of date fields that aren't time stamps but
just store dates. The problem is that when i load them into a java
Date it automatically assigns the timezone. The result will be a date
with 0 hours, 0 minutes, 0 seconds and the time zone of the server.
Like 02/20/2009 00:00:00 CST.
My application is a client server app using rmi. When the date is
passed to the client through all of the sudden the time zone which was
auto assigned when the date was populated from the server can change
the actual date. So if on the server I have 02/20/2009 00:00:00 CST
and the client is on pacific time then the date shows as the day
before. Because that date in pacific standard time is 02/19/2009
23:00:00 PST
So is there a way for all my dates to be completely ignorant of time
zones?
The same time *can* be two different days in two different timezones.
The two most obvious solutions for your requirement to have client
show server date are:
- have the server do the formatting and send String instead of DateTime
This would work but I was really hoping to avoid it, it is a pain to
maintain and just kind of kludgy. It seems to me that java should
have a date class without time and timezone. Every database has a
date type and a timestamp type, yet java doesn't support just date
types. What surprises me more is that this doesn't appear to be a
common issue.
None of the classes java.util.Date, java.sql.Date etc. has
timezone - they basically contains number of milliseconds since
1-Jan-1970 00:00:00 in London.
It is all in the formatting!

Yes! For example,

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

public class Date1 {

private static final String s = "EEE MMM dd HH:mm:ss z yyyy";
private static final DateFormat f = new SimpleDateFormat(s);

public static void main(String[] args) {
Date now = new Date();
print("US/Eastern", now);
print("Europe/London", now);
print("Europe/Copenhagen", now);
print("Australia/Sydney", now);
}

private static void print(String tz, Date d) {
f.setTimeZone(TimeZone.getTimeZone(tz));
System.out.println(f.format(d)
+ " " + d.getTime()
+ " " + tz);
}}

</code>

<console>
Sat Feb 21 14:47:28 EST 2009 1235245648606 US/Eastern
Sat Feb 21 19:47:28 GMT 2009 1235245648606 Europe/London
Sat Feb 21 20:47:28 CET 2009 1235245648606 Europe/Copenhagen
Sun Feb 22 06:47:28 EST 2009 1235245648606 Australia/Sydney
</console>

The problem is I want it to print the same date no matter what the
timezone. I am just trying to deal with the date portion and I don't
understand why java doesn't have a Date only date/time class.

Johns code shows you how to solve that problem.

Explicit specify the same timezone everywhere.

(and use a format with only the date parts)

Arne

 

[Arne Vajhøj]

Arne- I am sorry but I don't understand what you mean by it is just
formatting. In my database i only store a date type that includes
month, day, year. When I load that into a Date class it automatically
assigns the local timezone and i get 02-21-2009 00:00:00 CST or
whatever the time zone is. If that date is then viewed on a client on
PST then it is 02-20-2009 22:00:00 PST. So the date portion shows the
day before.

When you load a DATE column in your database over in a java.sql.Date
class, then you get the number of milliseconds since 1970.

When you write it out you apply a timezone to that to get a
string.

Default it uses the timezone of the computer.

But you can explicitly specify another timezone.

Arne

 

[Lew]

Arne- I am sorry but I don't understand what you mean by it is just
formatting. In my database i [sic] only store a date type that includes
month, day, year. When I load that into a Date class it automatically
assigns the local timezone and i [sic] get 02-21-2009 00:00:00 CST or
whatever the time zone is. If that date is then viewed on a client on
PST then it is 02-20-2009 22:00:00 PST. So the date portion shows the
day before.

What he means is that java.util.Date does not store timezone information. All
that information is added by the code that displays the value - that is what
"just formatting" means.

Let me repeat that: java.util.Date does not store timezone information. There
is no "automatically assigns the local timezone" when you store a value into a
Date. It all happens on the formatting of the display of the value.

All java.util.Date stores is a 'long' value. Classes like java.util.Calendar
and java.text.DateFormat store timezones, but java.util.Date does not.