On Jan 14, 2009, at 9:11 AM, Barði Einarsson wrote:
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.
Well, that depends on what you expect. :-)
The mismatch in the use of default time zones between NSTimestamp
and GregorianCalendar is a bug.
If it is, it is a bug in GregorianCalendar. Try setting it like this:
GregorianCalendar cal = new GregorianCalendar();
cal.clear();
cal.setTime(aDate);
Comments please.
I think it is important to distinguish between the real time (an
absolute point in time) and the name that time is called. The real
time never changes. The name we choose to call it does change as we
move from time zone to time zone. The best practice is to store the
real time (the time in GMT in the case of WO), and use formatters to
control the name that we show to the user.
Chuck
-----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
--
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
_______________________________________________
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]
