Hi, Andrew,
Given the current state of the Date/Time/Calendar classes between WO
and Java, yours seems to be one of the more cogent and straight
forward approaches that I've seen. It even seems to work (if one
either uses the add() methods on the Calendar class or remembers the
idiosyncrasies of the set() methods).
I would also like to see anyone else's approach if they've thought
the problem through and if it differs significantly from yours.
I still believe that the combination of Time/Date/Calendar classes
between WO and JSEE are broken and dangerous. Particularly so since
the errors that occur are often seldom tested boundary conditions,
e.g. adding a month to 1/30/2005 then adding another month and
watching what happens to the DAY_OF_MONTH, adding a day to 4/2/2005
or 10/1/2005 in the US and watching the time shift (I'm not sure what
the NZ daylight savings time laws are, but those are the DST
boundaries in the US this year). And what's with Java's Calendar
offsetting the month by ZERO??? Who in their right mind would do
that? Of if they would do that, why aren't the other numbers (e.g.
DAY_OF_WEEK, DAY_OF_MONTH) offset similarly.
Admittedly, when addressed globally, time and calendar concepts are
not simple, but I feel the present classes add as many complexities
and gotcha's as they remove.
Regards,
Jerry
On Jan 25, 2006, at 7:10 PM, [EMAIL PROTECTED] wrote:
Hello Jerry;
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...
I had the same problems some years ago getting a date/time
infrastructure setup. Here's a rundown on how things worked out
for me. Note that this isn't qualified as being a "right way" to
do things as I have largely developed this strategy in isolation,
but it seems to work out well. I'd welcome feedback on this.
I do the following in my app constructor...
TimeZone tz = java.util.TimeZone.getTimeZone("GMT+0000");
TimeZone.setDefault(tz);
NSTimeZone.setDefault(tz);
This means that all timestamps within the application are relative
to GMT. Then I store a "java.util.TimeZone" instance in the
session object allowing each "user" to have a different timezone.
I created my own date parsers/formatters which (like NeXT's ones
which I discovered some time later) have a presentation timezone
and a data timezone. My formatters are straight J2SE inside, but
subclasses translate using millisecond times between
"java.util.Date" and "NSTimesamp" on the fly. Formatting takes the
timestamps from data to presentation timezone and parsing takes the
timestamp from presentation to data timezone. The session has
methods to provide these formatters which upon first invocation set
the data timezone to GMT and the presentation timezone to the
session timezone on the formatter. There are formatters for dates
and formatters for dates-and-times accessible from my session
instances. On elements such as "WOTextField", I do not use the
"numberformat" or "dateformat" bindings, but just bind "formatter"
to my own formatters supplied by the session object. In this way,
every date or time the user sees is in their timezone, but inside
the WOA it is GMT all the way through.
When I need to manipulate timestamps using date arithmetic, I use a
GregorianCalendar which you can setup to operate in a particular
timezone. When you set the time on this GregorianCalendar
instance, use the method "setTimeInMillis(...)" instead of "setTime
(...)" and you can use the method "getTime()" on the NSTimestamp
instance to get the millisecond time. Don't forget to fiddle the
millisecond time into the right timezone first!
Basically if you need to move time between the WebObjects world and
J2SE world, make sure that you construct dates and so on with long
millisecond values.
I wanted some special behaviours from my formatters so I'm not sure
how all this would be using the native "NSTimestampFormatter".
cheers.
___
Andrew Lindesay
www.lindesay.co.nz
--
__ 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]
