Bug ID 6342679: NSTimestamp Happy New Year Bug
Bug ID 6342679: NSTimestamp Happy New Year Bug
- Subject: Bug ID 6342679: NSTimestamp Happy New Year Bug
- From: Barði Einarsson <email@hidden>
- Date: Wed, 14 Jan 2009 10:11:16 -0000
- Thread-topic: Bug ID 6342679: NSTimestamp Happy New Year Bug
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@hidden]
Sent: Tue 13-Jan-09 17:59
To: Barði Einarsson
Cc: email@hidden
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@hidden]
> 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@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
>
>
> 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@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden