how to make dates without timezones?

[Lew]

epicwinter wrote:

You quoted the sig.

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

That's why there's java.text.DateFormat, as we keep mentioning.

 

[epicwinter]

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

Well I just tried setting it up so my server would auto switch back
and forth between the client's time zones. So for each RMI request
the server says where is this client coming from and then calls
TimeZone.setDefault.

Unfortunately i couldn't get that to work because it doesn't seem to
be thread safe. It changes it for the entired java virtual machine
and then if another client makes a call from a different timezone it
will switch the timezone for all the client requests. I thought this
would be a winner...frustrating.

The problem I have with just formatting the data on the client side is
that the bulk of the work in my app is done on the server and is
served up to the client. So reports and such are generated in the
server and end up having the timezone of the server.

 

[Arne Vajhøj]

Well I just tried setting it up so my server would auto switch back
and forth between the client's time zones. So for each RMI request
the server says where is this client coming from and then calls
TimeZone.setDefault.

Unfortunately i couldn't get that to work because it doesn't seem to
be thread safe. It changes it for the entired java virtual machine
and then if another client makes a call from a different timezone it
will switch the timezone for all the client requests. I thought this
would be a winner...frustrating.

The problem I have with just formatting the data on the client side is
that the bulk of the work in my app is done on the server and is
served up to the client. So reports and such are generated in the
server and end up having the timezone of the server.

I would prefer one of:
- use an explicit formatting to server timezone in client
- format on server and send string to client

But if you want to have the server use the clients timezone,
then create a DateFormat/Calendar for the individual client
with the correct timezone and use that for format/parse/split.

Arne

 

[epicwinter]

I would prefer one of:
- use an explicit formatting to server timezone in client
- format on server and send string to client

But if you want to have the server use the clients timezone,
then create a DateFormat/Calendar for the individual client
with the correct timezone and use that for format/parse/split.

Arne

I think your suggestion of having an individual DateFormat for each
client that my server uses would work, but i am cringing at the
thought of how much code i will have to change.

I really would like to figure out how to set my server timezone to my
clients on a per call basis. It would solve all these problems and
wouldn't entail the custom formatter being applied throughout my app
(which is very large). There has to be a way to do this. I need to
set a currentthread.timezone vs user.timezone property.

 

[Lew]

I really would like to figure out how to set my server timezone to my
clients on a per call basis. It would solve all these problems and
wouldn't entail the custom formatter being applied throughout my app
(which is very large). There has to be a way to do this. I need to
set a currentthread.timezone vs user.timezone property.

It's called a local variable which you allocate to handle the individual
client request. Your suggested global approach is an antipattern.

For each request, determine the client time zone, or perhaps establish it at
the beginning of a client session and keep it for the duration of the session.

Apply that timezone in a java.text.DateFormat (and/or Calendar) used to serve
up the individual response for that client.

It's much more idiomatic Java, much easier to maintain, and much less likely
to give you trouble.

Don't change the entire server for each client. As you noticed, it's
horrendously un-thread-safe, and difficult to maintain, and will destroy
performance.

Get used to the idea of transient instances that hold request state or session
state. The pattern is something like this (pseudo-code with error-checking
omitted - don't omit it in real life):

public Response handleRequest( Request request )
{
String tzName = request.get( "timezone" );
TimeZone tz = TimeZone.getTimeZone( tzName );
DateFormat df = DateFormat.getDateInstance();
df.setTimeZone( tz );

doSomeRelevantProcessing(); // hand-waving for real work

Date dt = new Date();
String displayedDate = df.format( dt );

Response response = new Response();
response.setDisplayedDate( displayedDate );
// etc.
}

 

[John W Kennedy]

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.

Taken as written, that last sentence is utter nonsense; I assume,
therefore, that there is a missing "sometimes" between "we" and "use".

So establish a standard timezone (UTC is as good as any other) and store
and retrieve with it uniformly. End of problem.

 

[Karl Uppiano]

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.

Java *does* have a date type that is truly time zone ignorant: long. It is
the time in milliseconds since January 1, 1970 UTC. It is the value you get
when you say System.currentTimeMillis. You can convert that for display, to
local time, server time, UTC, or any other time zone you want, when you want
to display it. java.util.Date and java.sql.Date and java.sql.Time all wrap
long, and they contain no time zone information at all. If you call
toString, it *will* format the time into a string using the local time zone,
but toString is intended primarily as a diagnostic tool. Most other methods
on those classes are deprecated because date/time localization is not a
trivial issue -- they don't really work. java.util.Calendar is currently the
preferred way to deal with date/time localization in Java. Use
java.text.DateFormat for more flexible capabilities (it uses
java.util.Calendar internally to do its work).

 

[Karl Uppiano]

Well I just tried setting it up so my server would auto switch back
and forth between the client's time zones. So for each RMI request
the server says where is this client coming from and then calls
TimeZone.setDefault.

Yikes! I would not do this. I would store all times on the server as a long
in milliseconds since Jan 1, 1970 UTC. Then I would use java.text.DateFormat
set to the client's local time to format the date on the server, or allow
the client to format the date at their end. You might have to send the
client's time zone as a parameter in your RMI request.

Unfortunately i couldn't get that to work because it doesn't seem to
be thread safe. It changes it for the entired java virtual machine
and then if another client makes a call from a different timezone it
will switch the timezone for all the client requests. I thought this
would be a winner...frustrating.

If you format the date at the server end, you certainly don't want to be
changing the server's time zone all the time. Leave it at the correct time
zone for the server, and use the client's time zone to format the date for
them. If the client sends their time zone as a parameter in the RMI request
to use with java.text.DateFormat, then it will be a local variable that is
inherently thread-safe.

The problem I have with just formatting the data on the client side is
that the bulk of the work in my app is done on the server and is
served up to the client. So reports and such are generated in the
server and end up having the timezone of the server.

Yup, just format the report using the client's locale. Have the client send
you their locale when they make the request. BTW, sending a locale is even
more general than sending a time zone. If you follow that pattern, Java will
generate locale-appropriate number formats, time/date formats automagically.
And if you use resource bundles to translate strings, you'll get the right
language translations too.

 

[Karl Uppiano]

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

Then you are using the wrong class. Simply make a class that has the raw
month, day, year values that you have stored in your database, and serialize
that. java.util.Date was specifically designed to translate times to local
time based on the local time zone. You are needlessly fighting that
behavior, which most people want, by the way.

Incidentally, if you are using anything but a long to initialize Date, you
are using deprecated methods, which are not recommended for new projects.
They are deprecated because they mislead the programmer, and give the kind
of unexpected results that you are experiencing.

 

[Dr J R Stockton]

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

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

Incorrect. Between 1968-02-18 and 1972-03-19, the UK had GMT+1 all the
time. From 1968-10-27 to 1971-10-31, it was called British Standard
Time, otherwise British Summer Time. Both BST.

The Epoch, in London, was 1970-01-01 01:00:00 local time.

One must be ready to distinguish between the time used in Greenwich
(these days, UTC or UTC+1), the legal time in Greenwich (still GMT or
GMT+1, though it has been GMT+2), Greenwich Mean Time itself, and UTC.

It is the number of milliseconds, ignoring Leap Seconds, since
1970-01-01 00:00:00 UTC.

I don't know how big a long is, but 32 bits are not enough.

 

[Dr J R Stockton]

In comp.lang.java.programmer message <[email protected].
sbc.com>, Sat, 21 Feb 2009 11:04:14, Mark Space

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.

Indeed, there are two types of date, with an overlap. Or, rather, there
are three types of date.

One type is like the date of Easter, or Christmas, or other Birthdays :
the same date everywhere on the world (Orthodox Christians etc.
disregarded). That can be called a Chronological Date, since it is what
historians use.

The other two are the sort of date which, combined with a time of day
and an offset from UTC, indicates a single absolute instant in a
location-dependent manner; for one, the offset from UTC is the local
clock offset, for the other it is zero regardless of location.

For those whose clocks are never adjusted either for Summer & Winter or
to agree with [different] neighbours, either can be used, though it's
not reasonable to use a local date for non-local purposes.

Otherwise, one should use local dates for local events, UTC dates for
events not associated with a terrestrial locality, and Chronological
dates for ordinary life where clock changes either do not occur or can
be disregarded.

A system that handles only dates can be considered as, and implemented
by, a system that handles UTC date/time with time=00:00:00. One can
also use UTC methods to handle local date/time whenever the offset can
be disregarded - but then, ignoring Jet Stream effects, flying across
the Atlantic takes eight or ten hours longer Eastbound than Westbound.

UTC methods should be faster than local methods, because there os no
offset from UTC to be determined.


If necessary, it is easy enough to write code, using just general-
purpose programming operations, to convert between Year-Month-Day and
daycount. and to do input, output, and validation; methods, albeit not
Java, are via sig.


My anchor <URL:http://www.merlyn.demon.co.uk/estr-bcp.htm#TNS>
is immediately preceded by Easter code in JavaScript,
Pascal/Delphi, and C; I'd be pleased to add a good Java
version.

 

[Tom Anderson]

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.

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

 

[Tom Anderson]

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.

Taken as written, that last sentence is utter nonsense; I assume, therefore,
that there is a missing "sometimes" between "we" and "use".

Oh, come off it. I use a knife and fork. I don't need to say "i sometimes
use a knife and fork". "We use" does not mean "we only use".

tom

 

[Roedy Green]

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.

You can store them as longs. This is ms since 1970 UTC. That gives
you an invariant, but the database sees them as number not dates,
which could screw up ad hoc queries.

SimpleDateFormat.setTimeZone lets you display the same instant in time
as it would be in any timezone you please, normally the user's or UTC.

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.

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

 

[Lew]

java.util.Date was specifically designed to translate
times to local time based on the local time zone.

This is completely wrong, exactly contrary to the point the rest of us are
making to the OP. Please do not add to their confusion.

According to the Javadocs:

the Date class is intended to reflect coordinated universal time (UTC)

The 'long' returned by 'getTime()' contains

the number of milliseconds since January 1, 1970, 00:00:00 GMT
represented by this Date object.

When you use its 'setTime(long)' method, you set it

to represent a point in time that is time milliseconds
after January 1, 1970 00:00:00 GMT.

It most definitely is *not* "designed to translate times to local time based
on the local time zone". The only way one could defend that interpretation is
by referring to deprecated methods, and it is a Very Bad Thing to recommend
that anyone use the deprecated methods of Date.

Let's keep things straight here, shall we?

 

[Lew]

Oh, come off it. I use a knife and fork. I don't need to say "i
sometimes use a knife and fork". "We use" does not mean "we only use".

Oh, come off it, Tom. The whole point of John's answer is to correct
epicwinter's misapprehensions about the use of Date, in the context of which
the OP was apparently trying to make the case that the primary use of Date
should be for time-zone-ignorant processing. In order to make the point that
the main use is not for such processing, it was perfectly valid to contradict
the implication clearly made in the original phrasing, in its original
context. Just because it could have been interpreted differently in a
different context doesn't mean that John's answer was misleading.

 

[Arne Vajhøj]

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


Incorrect. Between 1968-02-18 and 1972-03-19, the UK had GMT+1 all the
time. From 1968-10-27 to 1971-10-31, it was called British Standard
Time, otherwise British Summer Time. Both BST.

The Epoch, in London, was 1970-01-01 01:00:00 local time.

So UK was using central european time a few years back then.

Interesting - I had no idea.

But it does not change the point.

One must be ready to distinguish between the time used in Greenwich
(these days, UTC or UTC+1), the legal time in Greenwich (still GMT or
GMT+1, though it has been GMT+2), Greenwich Mean Time itself, and UTC.

It is the number of milliseconds, ignoring Leap Seconds, since
1970-01-01 00:00:00 UTC.

I don't know how big a long is, but 32 bits are not enough.

A java long is 64 bit, so it is big enough.

Arne

 

[Lew]

A java [sic] long is 64 bit, so it is big enough.

The width of the types in Java is a fundamental aspect of the language. One
of the things that makes it WORA is that the language defines the width of its
primitives.

A few moments with the JLS will establish the facts if they slip one's mind.
<http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2>

 

[Dr J R Stockton]

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.

Time Zones are geographically fixed, and are not affected by seasons.

 

[Karl Uppiano]

This is completely wrong, exactly contrary to the point the rest of us are
making to the OP. Please do not add to their confusion.

It *was* specifically designed to do that. All of those methods are
deprecated now because it was ill-advised. Date.toString still formats 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. But for
many of us concerned with localized time, it is acceptable behavior for
debugging.

According to the Javadocs:

The 'long' returned by 'getTime()' contains

When you use its 'setTime(long)' method, you set it

It most definitely is *not* "designed to translate times to local time
based on the local time zone". The only way one could defend that
interpretation is by referring to deprecated methods, and it is a Very Bad
Thing to recommend that anyone use the deprecated methods of Date.

Which I emphasized in the *very next paragraph*.

Let's keep things straight here, shall we?

That was my intention. 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* 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.

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