OK, so when one gives NSTimestamp a null as a time zone it uses GMT, not the default time zone.
However, GregorianCalendar uses the default time zone. So, if one wants to use time zones with NSTimestamp, not just GMT, one has to explicitly specify the default time zone in the NSTimestamp constructor. Otherwise, GregorianCalendar will give one unexpected results. The mismatch in the use of default time zones between NSTimestamp and GregorianCalendar is a bug. Comments please. Best regards, Bardi -----Original Message----- From: Chuck Hill [mailto:[email protected]] Sent: Wed 14-Jan-09 15:15 To: WebObjects (Group) Cc: Barði Einarsson Subject: Re: Bug ID 6342679: NSTimestamp Happy New Year Bug On Jan 14, 2009, at 3:30 AM, Ken Anderson wrote: > NO! It is NOT an incorrect result! The reason you get the result > of 1963 when you use 1964 is because Reykjavik is 1 hour off from > GMT then. As confusing as it may be, Ken is correct. It is your understanding of how date/times are manipulated that is at fault. This is a complex and confusing area. If you use noon 12:00:00 instead of midnight 00:00:00 in the test dates the result should be as you expect as the time shift will only affect the time portion. The time shift will still happen, but it won't affect the day, month, or year. Chuck > On Jan 14, 2009, at 5:11 AM, Barði Einarsson wrote: > >> Ken >> >> If I use Atlantic/Reykjavik the code produces incorrect >> results. So, it is a bug. >> >> If I use GMT instead the code would work. That is a >> work around for a bug. >> >> Do you agree? >> >> Best regards, >> Bardi >> >> >> -----Original Message----- >> From: Ken Anderson [mailto:[email protected]] >> Sent: Tue 13-Jan-09 17:59 >> To: Barði Einarsson >> Cc: [email protected] >> Subject: Re: Bug ID 6342679: NSTimestamp Happy New Year Bug >> >> Bardi, >> >> OK - it took me all of 10 minutes to solve this. >> >> 1. You choose Atlantic/Reykjavik, not GMT, like we suggested. >> 2. In 1969, Iceland stopped respecting Daylight Savings Time: >> http://www.timeanddate.com/worldclock/timezone.html?n=211&syear=1960 >> >> >> date in yearFromDate : 1968-01-01 00:00:00 Etc/GMT >> yearFromDate : 1967 >> TimeZone:Atlantic/Reykjavik >> date in yearFromDate : 1969-01-01 00:00:00 Etc/GMT >> yearFromDate : 1969 >> >> If you had chosen GMT, where there's no shifts for daylight savings >> time, it's always accurate. >> >> Ken >> >> On Jan 13, 2009, at 12:02 PM, Barði Einarsson wrote: >> >>> It is a bug: >>> >>> run happyNewYear(1964) >>> >>> output: >>> >>> TimeZone:Atlantic/Reykjavik >>> date in yearFromDate : 1964-01-01 00:00:00 Etc/GMT >>> yearFromDate : 1963 >>> >>> >>> package some.packagename; >>> >>> import java.util.GregorianCalendar; >>> import java.util.TimeZone; >>> >>> import com.webobjects.foundation.NSTimeZone; >>> import com.webobjects.foundation.NSTimestamp; >>> >>> public class HappyNewYear { >>> >>> static { >>> TimeZone.setDefault(TimeZone.getTimeZone("Atlantic/ >>> Reykjavik")); >>> NSTimeZone.setDefault(TimeZone.getTimeZone("Atlantic/ >>> Reykjavik")); >>> } >>> >>> >>> public static int yearFromDate(NSTimestamp date) { >>> if (null == date) { >>> return 0; >>> } >>> System.out.println("TimeZone:" + >>> TimeZone.getDefault().getID()); >>> GregorianCalendar cal = new GregorianCalendar(); >>> cal.setTime(date); >>> System.out.println("date in yearFromDate : " + date); >>> int result = cal.get(GregorianCalendar.YEAR); >>> System.out.println("yearFromDate : " + result); >>> return result; >>> } >>> >>> public static void happyNewYear(int year) { >>> NSTimestamp newYear = new NSTimestamp(year, 1, 1, 0, 0, 0, null); >>> yearFromDate(newYear); >>> } >>> >>> } >>> >>> >>> >>> -----Original Message----- >>> From: Ken Anderson [mailto:[email protected]] >>> Sent: Fri 09-Jan-09 15:23 >>> To: Lachlan Deck >>> Cc: Barði Einarsson; WebObjects-Dev Mailing List List >>> Subject: Re: Bug ID 6342679: NSTimestamp Happy New Year Bug >>> >>> Bardi, >>> >>> I think the most important thing to understand about how dates are >>> moved around is that the value is always GMT based. Timezones are >>> there for convenience... >>> >>> For instance, when you create a new timestamp with a timezone, the >>> timezone is used to adjust the date/time you sent in to GMT and the >>> GMT value is stored. When formatting a date or extracting day/ >>> month/ >>> year from GregorianCalendar, the timezone is used WHEN FORMATTING >>> THE >>> RESULT. >>> >>> If you work with these tenets, things will hopefully be easier. >>> >>> Ken >>> >>> On Jan 8, 2009, at 6:54 PM, Lachlan Deck wrote: >>> >>>> On 09/01/2009, at 3:10 AM, Ken Anderson wrote: >>>> >>>>> I do exactly what you're doing all the time, and I do not have the >>>>> issue you're experiencing. One thing I do at the beginning of my >>>>> WOApplication subclass is this: >>>>> >>>>> TimeZone.setDefault(TimeZone.getTimeZone("GMT")); >>>>> NSTimeZone.setDefault(TimeZone.getTimeZone("GMT")); >>>>> >>>>> This will make sure that you're really working in GMT across the >>>>> board. Can you do the above and try your tests again? >>>> >>>> Yep. >>>> >>>>>> Behaves correctly - no way >>>> >>>> Yes way :-) >>>> >>>>>> NSTimestamp reports a timezone which is not used by >>>>>> GregorianCalendar ?? >>>> >>>> GregorianCalendar does *not* change its timezone based on the date >>>> passed to it. You are responsible for determining that. That's >>>> nothing to do with NSTimestamp. >>>> >>>>>> This is a difficult bug. >>>> >>>> Just more a misunderstanding on your part. >>>> >>>> with regards, >>>> -- >>>> >>>> Lachlan Deck >>>> >>>> _______________________________________________ >>>> 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/kenlists%40anderhome.com >>>> >>>> This email sent to [email protected] >>> >>> >>> >>> Fyrirvari á tölvupósti / e-mail disclaimer >>> http://us.is/Apps/WebObjects/US.woa/wa/dp?id=3776 >>> >>> >>> _______________________________________________ >>> 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/kenlists%40anderhome.com >>> >>> This email sent to [email protected] >> >> >> >> Fyrirvari á tölvupósti / e-mail disclaimer >> http://us.is/Apps/WebObjects/US.woa/wa/dp?id=3776 >> >> > > _______________________________________________ > 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/chill%40global-village.net > > This email sent to [email protected] > -- Chuck Hill Senior Consultant / VP Development 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 Fyrirvari á tölvupósti / e-mail disclaimer http://us.is/Apps/WebObjects/US.woa/wa/dp?id=3776 _______________________________________________ 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]
