If you use a formatter when displaying your time, or within a text field for form entry, you don't have to worry about pushing your Timestamp into the correct zone for display. The formatter will take care of all the adjustments for you. With the formatter you can stick to the data as it's stored and avoid converting it into (or out of) GregorianCalendar.
HI Mark,
Thanks for the help, I am working with those calls and I did give up using the combined timestamp/timezone entity inside the database.
My re-construction code in the EOGenericRecord sub-class is failing, the dates are now 3 days off and the DST is the same?
public NSTimeZone timeZoneObj() {
Number timezone = timeZone();
if ( timezone == null ) return NSTimeZone.defaultTimeZone();
int gmtOffset = timezone.intValue();
return NSTimeZone.timeZoneForSecondsFromGMT( gmtOffset );
}
public NSTimestamp eventDateTimeZone() {
GregorianCalendar gcDateTime = new GregorianCalendar();
gcDateTime.setTime( eventDate() ); // eventDate is the <timestamp> in the database
return new NSTimestamp( gcDateTime.get(Calendar.YEAR), gcDateTime.get(Calendar.MONTH), gcDateTime.get(Calendar.DAY_OF_MONTH),
gcDateTime.get(Calendar.HOUR), gcDateTime.get(Calendar.MINUTE), 0, timeZoneObj() );
}
On Mar 9, 2007, at 10:54 AM, Mark Ritchie wrote:
On 7-Mar-07, at 11:34 AM, Baiss Eric Magnusson wrote:
It seems to me that I need to go back and associate a time zone id for all my events.
and then use this
tz = NSTimestamp.....
NSTimestamp myNSTimestamp = new NSTimestamp(year, month, day, hour, minute, seconds, tz)
Hi Baiss!
Use caution here! As had already been pointed out, NSTimestamp does not store time zone information. I believe that the tz argument in all the constructors is only used to interpret the other arguments.
Hmmm, might be my problem.
The docs say this for several of the constructors. The given information is converted and stored as millisecond offset since reference date in the reference timezone. That would be January 1, 1970, 00:00:00 GMT.
As Ken pointed out, you might be better of storing the local time and the time zone so that you can reconstruct the right times. Alternatively, you might find: timestampByAddingGregorianUnits(int years, int months, int days, int hours, int minutes, int seconds) useful. The docs say that it preserves time of day across DST changes.
timestampByAddingGregorianUnits in the docs.
public NSTimestamp timestampByAddingGregorianUnits( int year, int month, int day, int hour, int minute, int second)
Deprecated in the Java Foundation framework. Don't use this method.
The bit that I'm really interested in for your app is why the time changes back to being correct in April. Makes me wonder if something isn't up to date!?
That's because the <timestamp> refers to Greenwich time zone by default and so when DST occurs there at the end of March the time syncs back.
Hope that helps!
Mark