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.
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.
Regards,
Jerry
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 protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/jerrywwalker%
40gmail.com
This email sent to [EMAIL PROTECTED]
--
__ Jerry W. Walker,
WebObjects Developer/Instructor for High Performance Industrial
Strength Internet Enabled Systems
[EMAIL PROTECTED]
203 278-4085 office
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
