how to make dates without timezones?

[epicwinter]

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.

Fair enough, but by default it uses the timezone of the computer
whenever you get the values. What strategy would you recommend to
change it so I am ignorant of the timezone by default?

 

[John B. Matthews]

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

You can use a different format, but all of the above represent the same
instant in time, to the nearest millisecond. When I ran the program on
Saturday afternoon, it was early Sunday in the land down under.

Further upthread, you said,

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.

Are you perhaps using the deprecated Date#setXxx() methods when you
"load that into a Date" instance? I see that setYear(), setMonth(),
setDate(), etc. all use the "local time zone."

 

[epicwinter]

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

Using a java.sql.Date doesn't help. It still seems to display the
timezone data by default and consequentially switch the time and date
after on a change in timezone.

 

[epicwinter]

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

You can use a different format, but all of the above represent the same
instant in time, to the nearest millisecond. When I ran the program on
Saturday afternoon, it was early Sunday in the land down under.

Further upthread, you said,

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.

Are you perhaps using the deprecated Date#setXxx() methods when you
"load that into a Date" instance? I see that setYear(), setMonth(),
setDate(), etc. all use the "local time zone."

I am using hibernate to load my data from my db into my domain
objects.

As far as I know it isn't just setYear, setMonth, etc that use local
time zone, when you create a java.util.Date from a long it always
formats it using local time zone.

 

[Arne Vajhøj]

Using a java.sql.Date doesn't help. It still seems to display the
timezone data by default and consequentially switch the time and date
after on a change in timezone.

Almost no matter what you do, then you will have something
that represent the time since 1970.

But you can control how it is formatted. And that is how
you should solve your problem.

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

Fair enough, but by default it uses the timezone of the computer
whenever you get the values. What strategy would you recommend to
change it so I am ignorant of the timezone by default?

You can not convert a time to a string without using a timezone.

If you don't like the default timezone then specify a different one.

Arne

 

[Arne Vajhøj]

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

You can use a different format, but all of the above represent the same
instant in time, to the nearest millisecond. When I ran the program on
Saturday afternoon, it was early Sunday in the land down under.

Further upthread, you said,

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.

Are you perhaps using the deprecated Date#setXxx() methods when you
"load that into a Date" instance? I see that setYear(), setMonth(),
setDate(), etc. all use the "local time zone."

I am using hibernate to load my data from my db into my domain
objects.

As far as I know it isn't just setYear, setMonth, etc that use local
time zone, when you create a java.util.Date from a long it always
formats it using local time zone.

No.

The code is:

private transient long fastTime;
...
public Date(long date) {
fastTime = date;
}

It is the formatting that applies timezone.

Arne

 

[epicwinter]

Almost no matter what you do, then you will have something
that represent the time since 1970.

But you can control how it is formatted. And that is how
you should solve your problem.

Arne

Basically you are saying if I am using the date only fields then the
way to maintain the proper date format is always make sure when I
access/display the date it is in the same timezone that the server is
that loaded it?

This sounds like an absolute nightmare from a maintenance point of
view. There must be a more pragmatic way to solve this problem

 

[Arne Vajhøj]

Basically you are saying if I am using the date only fields then the
way to maintain the proper date format is always make sure when I
access/display the date it is in the same timezone that the server is
that loaded it?

This sounds like an absolute nightmare from a maintenance point of
view. There must be a more pragmatic way to solve this problem

No.

It has nothing to do with date only. A full timestamp have
the same issue.

If you have a true time of any kind, then transforming
it to a string requires a timezone, because the same time
is different textual in different timezones.

You can either get a default timezone or specify an explicit
timezone.

Arne

 

[epicwinter]

No.

It has nothing to do with date only. A full timestamp have
the same issue.

If you have a true time of any kind, then transforming
it to a string requires a timezone, because the same time
is different textual in different timezones.

You can either get a default timezone or specify an explicit
timezone.

Arne

Arne I still see this solution as a maintenance nightmare. You say
that it only applies timezone on formatting but if you want to get the
values of month day or year it is affected by the timezone you are in
using a java.util.Date. If it was just formatting then why do i have
to specify and explicit timezone? It seems to me that java is
dropping the ball on this one and needs a class that is truly timezone
ignorant, not one that is timezone ignorant until you access/display
the data and then you have specify that you want utc every single time
in order to not get a result that has time. If java.util.Date was
timezone ignorant then by default it would not format the date with a
time zone or with hours, minutes and seconds.

 

[Arne Vajhøj]

Arne I still see this solution as a maintenance nightmare. You say
that it only applies timezone on formatting but if you want to get the
values of month day or year it is affected by the timezone you are in
using a java.util.Date.

Hopefully not.

Those methods has been deprecated for a decade.

To translate a Date to components you should use Calendar.

Calendar also uses timezone info.

Obviously.

If it was just formatting then why do i have
to specify and explicit timezone?

You do if you want to format number of milliseconds to a
textual date and/or time - and you are not happy with the
timezone on the computer.

It seems to me that java is
dropping the ball on this one and needs a class that is truly timezone
ignorant, not one that is timezone ignorant until you access/display
the data and then you have specify that you want utc every single time
in order to not get a result that has time.

It is impossible to convert from a true time to a textual representation
without timezone.

If java.util.Date was
timezone ignorant then by default it would not format the date with a
time zone or with hours, minutes and seconds.

It is. It is basically just a long with number of milliseconds
since 1-Jan-1970 00:00:00 in London.

You need timezone when you format it or parse.

The relevant classes like DateFormat, Calendar etc. allows
you to set an explicit timezone if the default (the computers)
ate not good enough.

Arne

 

[Lew]

It is. It is basically just a long with number of milliseconds
since 1-Jan-1970 00:00:00 in London.

This is the point the OP needs to understand - java.util.Date does *not*
contain timezone information. It is, as they wish,because *all* it contains is those milliseconds.

You need timezone when you format it or parse.

The relevant classes like DateFormat, Calendar etc. allows
you to set an explicit timezone if the default (the computer's)
are not good enough.

Also, as Arne pointed out, do not use the deprecated methods of java.util.Date.

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. The hard news is you have to deal with it; you might as
well get used to it and start doing so now.

 

[Lew]

As far as I know it isn't just setYear, setMonth, etc that use local
time zone, when you create a java.util.Date from a long it always
formats it using local time zone.

Nonsense. A 'long' does not contain formatting.

 

[Lew]

Fair enough, but by default it uses the timezone of the computer
whenever you get the values. What strategy would you recommend to
change it so I am ignorant of the timezone by default?

You cannot be ignorant of timezone and still control the timezone when you
format the output. Since java.util.Date is ignorant of timezone, it is up to
the programmer to make sure the value is displayed according to the desired
timezone.

It is the fact that java.util.Date is ignorant of the timezone that requires
that the programmer not be. If the timezone of the computer is not the one
you want, then you are the one who has to apply the one you do want.

 

[Arne Vajhøj]

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

 

[Lew]

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

Yes, "that's the problem domain."

 

[epicwinter]

You cannot be ignorant of timezone and still control the timezone when you
format the output.  Since java.util.Date is ignorant of timezone, it is up to
the programmer to make sure the value is displayed according to the desired
timezone.

It is the fact that java.util.Date is ignorant of the timezone that requires
that the programmer not be.  If the timezone of the computer is not the one
you want, then you are the one who has to apply the one you do want.

See I don't want to control the timezone, I don't want time zone or
time related portion of the date, period.

 

[epicwinter]

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

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. So it seems to me that there should
be a built in java Date class that only stores month date year. I am
guessing this is contradictory to basing time as milliseconds since
epoch.

 

[Arne Vajhøj]

See I don't want to control the timezone, I don't want time zone or
time related portion of the date, period.

Date gives you that. You can also store the long you get out
with .getTime().

But as soon as you want a textual representation of the date
then you need a timezone, because it is different for different
timezones.

Arne

 

[Arne Vajhøj]

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. So it seems to me that there should
be a built in java Date class that only stores month date year. I am
guessing this is contradictory to basing time as milliseconds since
epoch.

It is correct that a specific birthday is not a specific time,
because the time depends on the timezone.

But for most apps that is handled very simply by using the
servers time for both parse and format. It gives perfectly
consistent results from the user perspective no matter
whether the time stored is actually part of the users
birthday in his timezone.

Your problem arise because you have distributed app. But I still
that letting the client app format using the servers timezone is
the solution. That is work, but distributed apps tend to be work.

Arne