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/archive%40mail-archive.com This email sent to [email protected]
