Re: NSTimestamp
Re: NSTimestamp
- Subject: Re: NSTimestamp
- From: "Jerry W. Walker" <email@hidden>
- Date: Wed, 25 Jan 2006 17:14:38 -0500
Hi, Welemski,
Begin forwarded message:
From: ".::welemski::." <email@hidden>
Date: January 25, 2006 12:39:49 AM EST
To: email@hidden
Subject: NSTimestamp
Hi,
I have a question about time/date and a like.
If I issued a command ;
NSTimestamp myTime=new NSTimestamp();
and deployed my app, will the current time of the "Server" will be
the one added in the "myTime" variable or
will it be on the "Client's" current time?
Actually, this is a bit more complicated than described by your other
respondents (shown below), but in practice, generally devolves to
what the others have said. Basically, the command:
NSTimestamp myTime=new NSTimestamp();
forces NSTimestamp to use the default time zone, or the result of
com.webobjects.foundation.NSTimeZone's getDefault() method.
If you check the JavaDoc documentation for that, you'll note that it
references Java's java.util.TimeZone as follows:
The default time zone returned by NSTimeZone may or may not be
consistent with the default time zone returned by
java.util.TimeZone.
If you check Java's java.util.TimeZone JavaDoc documentation, you'll
note the method:
public static void setDefault(TimeZone zone): Sets the TimeZone
that
is returned by the getDefault method. If zone is null, reset
the default
to the value it had originally when the VM first started.
Following that, note the method:
public static TimeZone getDefault(): Gets the default TimeZone for
this host. The source of the default TimeZone may vary with
implementation.
The general source of the default is that which is set for the Java
Virtual Machine. This is usually set by the system time of the host.
However, be careful because some web server hosts are set to GMT.
[rant on]:
Like most things associated with time fields in WebObjects, this is
broken. It's mildly broken in this case, other facets of this area
are thoroughly broken. In defense of the WebObjects' team at Apple,
the whole Time/Date/Calendar class area of Java has been going
through a major transition to take the original Java Time/Date/
Calendar classes and make them localizable. This has caused some
classes to have more deprecated methods than acceptable methods.
One of the more pernicious side effects of this has recently caused
me some hair loss. Namely the combination of the following two facts:
1) In order to extract subfields, such as month, date, hour, minute,
etc. from an NSTimestamp, you have to revert to the underlying Java
Calendar classes. In particular, Apple documents the following
recommendation in the NSTimestamp JavaDoc:
===================
To break up a NSTimestamp into its component year, month, day, hour,
etc., you can convert it into a java.util.GregorianCalendar and
invoke its get method on the individual fields:
NSTimestamp myNSTimestamp = new NSTimestamp();
GregorianCalendar myCalendar = new GregorianCalendar();
myCalendar.setTime(myNSTimestamp);
int year = myCalendar.get(GregorianCalendar.YEAR);
int dayOfMonth = myCalendar.get(GregorianCalendar.DAY_OF_MONTH);
===================
2) When using WebObjects in general, and NSTimestamp in particular,
one naturally tends to use its pair, NSTimeZone, rather than Java's
TimeZone. However, if you take the time to check Apple's JavaDoc on
NSTimeZone, you will note the following:
===================
Because NSTimeZone is a subclass of java.util.TimeZone, you can also
use the java.util.TimeZone API with NSTimeZones.
WARNING: NSTimeZone is only intended to be used with NSTimestamp and
NSTimestampFormatter. It produces incorrect results when used with
Java's date-related classes.
===================
BELIEVE THE WARNING!!! Using NSTimeZone with Java's
java.util.GregorianCalendar will cause it to offer irrational results
at times.
So, are they saying that you should only use NSTimeZone with an
NSTimestamp if you never intend to extract any of its date/time fields?
I hope they fix this area soon. And while they're at it, I hope they
include a couple convenience classes, such as a Date class whose
resolution goes no lower than just the date. No hours, no minutes, no
seconds, no milliseconds... just down to the day of the month and
provide it with an associated NSFormatter class.
The second convenience class I would like to see is ClockTime. I want
this class to have an associated formatter and represent what we all
mean when we say, I'll see you at 3:30 PM next Tuesday. We don't mean
3:30 PM GMT. We don't mean 3:30 PM DST or EST or PDT or and of the
other abbreviations. What we mean is, "I'll see you at the mutually
agreed location on the mutually agreed date when the clock on the
wall at that location says 3:30 and it's in the afternoon."
The concept I just described as ClockTime seems closely related to
NSTimestamp or Java's Timestamp until you have to start dealing
seriously with calendars. NSTimestamp deals very well with precise
intervals of time, but not nearly so well with coordinating time. So
if we're in standard time, and tomorrow morning we go into daylight
savings time, and I take an NSTimestamp value of 3:30 PM today and
add one day to it, I will end up with 4:30 PM tomorrow, which is not
at all the time I had intended to meet my friend!
It will, however, satisfy a scientist who wanted to stop an
experiment in exactly 24 hours, daylight savings time be d*mned.
My point here is not that NSTimestamp is wrong, but that it's
directed at one set of interests and there seem to be no classes
directed to the other in which we would like to be able to add days
to a calendar without worrying that things scheduled for 3:30 every
day this week will show up as 3:30 today but will show on the
calendar as 4:30 for tomorrow.
[end of rant]
Regards,
Jerry
On Jan 25, 2006, at 3:47 PM, Denis Stanton wrote:
On 26/01/2006, at 9:41 AM, Ray Ackland wrote:
I would add that this is based on the assumption that you are
doing a web app. If it was Java client – and this was in the
client class – then it would take the time stamp of that system.
On 25/01/2006, at 18:49, Denis Stanton wrote:
The system time on the server running the app will be added.
Your java code does not know anything about the client's system time
Good point Ray. I did wonder why welemski referred to the user as
'client'. I assumed he meant the same as 'browser'. He didn't
exactly specify java client, but that would be a sensible
assumption from the mention of 'client'.
Denis _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40gmail.com
This email sent to email@hidden
--
__ Jerry W. Walker,
WebObjects Developer/Instructor for High Performance Industrial
Strength Internet Enabled Systems
email@hidden
203 278-4085 office
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden