Re: NSCalendar bug with adding to pre-1919 dates?
Re: NSCalendar bug with adding to pre-1919 dates?
- Subject: Re: NSCalendar bug with adding to pre-1919 dates?
- From: Brett Powley <email@hidden>
- Date: Thu, 2 Mar 2006 08:33:25 +1100
On 02/03/2006, at 4:18 AM, John Stiles wrote:
Whether it's confusing or not, exactly one year after March 1, 1918
0:00 /is/ March 1, 1919 1:00. I don't think it's up for debate :)
I'm actually not persuaded by this. The one hour time difference
ought to appear if your starting date was before DST and your ending
date during DST. However, surely one year later DST has finished so
the time has gone *back* an hour again?
Unless there is some weirdness about 1918/1919.
Ben Kazez wrote:
This makes sense to me (use UTC intermediately and then convert to
the desired time zone). However, I just remembered that in
post-1918 dates, there's no DST issue when I add one day or one
month to a date across the DST boundaries. This works well for my
app, since I always want the time portion of the date to stay the
same. Regardless of the adoption of DST in 1918, wouldn't it be
more consistent if March 01, 1918 00:00:00 plus 1 year equalled
March 01, 1919 00:00:00?
Ben
On Mar 1, 2006, at 2:51 AM, Greg Herlihy wrote:
Since the time calculations are performed for a date and time in
a specific
time zone (apparently U.S. Eastern) it would make sense that the
time
reported would reflect any Daylight Saving Time adjustment needed
to arrive
at the correct, local time. (A little bit of trivia: the "Saving" in
"Daylight Saving Time" does not end in an "s").
If the calculations should be time-zone independent then UTC
(GMT) should be
the specified time zone.
Greg
On 2/28/06 10:44 PM, "Brett Powley" <email@hidden> wrote:
Daylight savings perhaps? Summer DST began for the first time
in the
US on March 31 1918, which is right in the middle of where your
weirdness happens...
On 01/03/2006, at 10:06 AM, Ben Kazez wrote:
I have an application that retrieves an NSCalendarDate from a .ics
file and adds one year to it until the date is within a certain
range. (This isn't the most efficient way to do things, but it's
fast enough for my needs.) This algorithm runs into a problem with
dates before 1919. Here's the line that adds the date components:
currentExpandedDate = [[IEPSystemCalendar
dateByAddingComponents:frequency toDate:currentExpandedDate
options:
0] dateWithCalendarFormat:BKWebScriptCalendarFormat timeZone:
[[unexpandedEvent objectForKey:@"DTSTART"] timeZone]];
The frequency variable is set to one year using -[NSDateComponents
setYear:]. As an example, here the app is starting with 1914-03-01
00:00:00 -0600:
March 01, 1915 00:00:00
March 01, 1916 00:00:00
March 01, 1917 00:00:00
March 01, 1918 00:00:00
March 01, 1919 01:00:00
March 01, 1920 01:00:00
...
(Sorry for the inconsistent date formatting.) As you can see,
after
1918, the date is one hour off. Does anyone know why this is
happening?
Ben
--------------------------------------------------------------
Brett Powley -- PhD Candidate
Centre for Language Technology, Macquarie University, Australia
w: http://www.ics.mq.edu.au/~bpowley
faciendi plures libros nullus est finis
frequensque meditatio carnis adflictio est
--------------------------------------------------------------
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden