Re: Date-Only NSTimestamps
Re: Date-Only NSTimestamps
- Subject: Re: Date-Only NSTimestamps
- From: Chuck Hill <email@hidden>
- Date: Thu, 3 Jan 2008 13:53:17 -0800
Hi Jerry,
On Jan 3, 2008, at 6:29 AM, Jerry W. Walker wrote:
Hi, Simon, et al,
Only slightly off topic, I've experienced many of the same problems
with time that this thread is dealing with for dates.
While working on a scheduling system, after only a few hours of
grieving, moaning, cussing and swearing at the Java time/date
classes, I realized that when my user says "I would like to meet
with you at 2:30 PM some day next week." What they really mean is
"I would like to meet with you when the clock on the wall at our
meeting location says 2:30 PM some day next week." What they don't
mean is "I would like to meat with you at 2:30 PM EST some day next
week." (Substitute your own time zone for "EST".) They don't mean
the latter because they typically don't even consider the
consequences of crossing a daylight savings time boundary during
any day of that week.
I think that is exactly the problem. Java is very exact and accurate
in representing dates and times as they cross DST and time zone
boundaries. In spoken and written language, we are much less exact.
If it is in the summer, and I set up a meeting for 11AM that winter,
I don't expect to see it as 10AM DST (or is that 12PM DST...). I
typed 11 and I meant 11! In other applications, that difference is
important. I don't think there is any one, right solution to this.
It needs to be handled on a case by case basis depending on the
application.
My solution was to write my own ClockTime class that was completely
divorced from date. This was a much more difficult solution than I
expected it to be, particularly when I added a custom formatter for
ClockTime. However, it considerably eased my pain overall.
Perhaps we should consider writing a new set of date/time classes
and methods in Project Wonder that more closely conform to the
original WO date/time classes than those of Java do. Then, when
faced with date/time problems, we could relieve some of our
personal burdens by doing it the WO way instead of the Java way. I
remember having problems with those classes as well, but they were
small potatoes to the problems I had moving to the Java date/time
classes.
Granted, this would only further separate a WO programmer from a
Java programmer, as WO's collection classes already do, but given
the date/time Hell provided by Java, it might be worth it.
I would be pleased to open my ClockTime and ClockTimeFormatter
classes for the community's review and refinement for any such effort.
The ClockTime classes sound interesting and could be the solution to
one set of problems. I am not sure there is any general purpose
solution. Avoiding the NSTimeZone class does make things more
reliable as things get updated.
Chuck
On Jan 3, 2008, at 2:58 AM, Simon McLean wrote:
It is a problem when the value is saved during DST and then
queried when DST is not in effect (or vice versa).
Aaahh, yes, I remember now. That's the big pain in the butt!
the default time time zone to GMT. But then you get a whole new
world of pain because you have to convert timestamps on the fly
for presenting to your users!
That actually turns out to be fairly easy because you use a
common datetime formatter on the session for all of the user's
time rendering. This can be used bi-directionally for
WOTextFields as well and then it is not too tricky at all to
achieve this.
I don't see how this is any different from what WO does already.
NSTimestamps are always in GMT and get formatted to / from the
local timezone. If you set the local timezone to GMT, you avoid
problems with new NSTimestamp, but you still have problems with
dates parsed from user input if you don't want to interpret that
as GMT values. What am I missing?
Good question :-) The new NSTimestamp() is the main problem solved
- including the querying in/out of DST. But let me change the tack
a little...
What if we store the user's literal input at GMT too (so if they
put 14:00 we store it at 14:00 GMT) then for the majority of uses
there is no need to change anything on the fly. We can just push
and pull values from the DB and display exactly what we get to the
user. Queries will never go wrong because there are no DST issues.
We are effectively normalising the timezone.
It then becomes an issue if you want to calculate the difference
in time between to points in different time zones (ie. user 1
enters a date/time in BST and user 2 enters a date/time in EST and
you want to calculate the difference between the 2 literal date/
time's). You could solve this by storing the timezone of each
record separately (i guess just as a the string abbreviation) and
having a cover method which converts the timestamp on the fly:
public NSTimestamp myTimeStamp; // assume it exists and is stored
in GMT.
public String myTimeZone; // assume it exists and is set to the
users timezone.
public NSTimestamp myTimeStampInMyTimeZone() {
GregorianCalendar gc = new GregorianCalendar();
gc.setTime(date);
int day = gc.get(GregorianCalendar.DAY_OF_MONTH);
int mth = gc.get(GregorianCalendar.MONTH) + 1;
int year = gc.get(GregorianCalendar.YEAR);
int hour = gc.get(GregorianCalendar.HOUR_OF_DAY);
int min = gc.get(GregorianCalendar.MINUTE);
int sec = gc.get(GregorianCalendar.SECOND);
NSTimeZone tz = NSTimeZone.timeZoneWithName(myTimeZone, true);
return new NSTimestamp(year, mth, day, hour, min, sec, tz);
}
What else could go wrong ?
Simon
_______________________________________________
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
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
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