227.srt

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:00:00.506 --> 00:00:09.496 A:middle
[ Silence ]

00:00:09.996 --> 00:00:12.926 A:middle
>> Hello and welcome to
Solutions to Common Date

00:00:12.926 --> 00:00:15.326 A:middle
and Time Challenges,
I'm Chris Kane.

00:00:16.036 --> 00:00:20.916 A:middle
Now, two years ago at WWDC
2011 I gave a very similar talk

00:00:21.356 --> 00:00:25.336 A:middle
called Performing Calendrical
Calculations and I--

00:00:25.536 --> 00:00:29.556 A:middle
you can go on the develop site
at apple.com and find the video

00:00:29.556 --> 00:00:31.256 A:middle
for that and watch that too.

00:00:31.406 --> 00:00:35.146 A:middle
But I promise for this talk
I have some all new content.

00:00:35.146 --> 00:00:37.006 A:middle
So, this talk is not really--

00:00:37.096 --> 00:00:40.506 A:middle
not just a duplication
of that talk 2 years ago.

00:00:40.506 --> 00:00:43.386 A:middle
What I'm going to be
doing today is I'm going

00:00:43.386 --> 00:00:46.636 A:middle
to give you a brief introduction
to the calendar APIs,

00:00:47.636 --> 00:00:53.006 A:middle
these are the APIs that one
uses to do calendar operations,

00:00:53.796 --> 00:00:55.556 A:middle
calendrical calculations
if you will

00:00:55.626 --> 00:00:57.366 A:middle
and I'll be explaining that.

00:00:57.366 --> 00:01:00.846 A:middle
Then the bulk of
the talk is going

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:00:57.366 --> 00:01:00.846 A:middle
Then the bulk of
the talk is going

00:01:00.846 --> 00:01:03.966 A:middle
to be spent covering
several common tasks

00:01:03.966 --> 00:01:07.146 A:middle
that we see people doing over
and over again, and I'm going

00:01:07.146 --> 00:01:10.186 A:middle
to talk about how I
would go about, you know,

00:01:10.186 --> 00:01:12.066 A:middle
doing those kinds of operations.

00:01:12.846 --> 00:01:17.036 A:middle
Now, my examples are going to
use some new methods that are

00:01:17.136 --> 00:01:24.986 A:middle
in Mavericks OS X, Mavericks,
but not yet in iOS watch

00:01:24.986 --> 00:01:29.836 A:middle
for a future update in iOS
for those APIs to appear.

00:01:29.996 --> 00:01:34.056 A:middle
They're not here in your
seed for example, iOS seed.

00:01:35.476 --> 00:01:38.026 A:middle
Finally, I'm going to wrap
up with just a few words

00:01:38.026 --> 00:01:41.686 A:middle
about testing calendar
calculations.

00:01:42.656 --> 00:01:46.166 A:middle
And then give you some more
information about where to look

00:01:46.816 --> 00:01:50.436 A:middle
for additional resources
and stuff like that.

00:01:51.006 --> 00:01:51.956 A:middle
So, let's dive in.

00:01:52.286 --> 00:01:56.196 A:middle
So, when I talk about the
calendar APIs, I'm referring

00:01:56.196 --> 00:02:01.486 A:middle
to just these 4 classes here,
NSDate, NSDateComponets,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:01:56.196 --> 00:02:01.486 A:middle
to just these 4 classes here,
NSDate, NSDateComponets,

00:02:01.896 --> 00:02:04.156 A:middle
NSCalendar and NSTimeZone.

00:02:05.066 --> 00:02:07.256 A:middle
Now, if you wanted to present
information to the user

00:02:07.256 --> 00:02:09.205 A:middle
on the screen like
display a date,

00:02:09.205 --> 00:02:12.016 A:middle
you would use a class
called NSDate Formatter.

00:02:12.016 --> 00:02:14.806 A:middle
I'm not going to be talking
about NSDate formatter

00:02:14.806 --> 00:02:18.246 A:middle
in this particular talk
but you can go look about--

00:02:18.246 --> 00:02:20.076 A:middle
look at the documentation

00:02:20.076 --> 00:02:24.906 A:middle
for NSDate formatter
online or an Xcode.

00:02:25.046 --> 00:02:26.716 A:middle
So, what is an NSDate?

00:02:27.556 --> 00:02:30.536 A:middle
Well, NSDate is a very
simple value object

00:02:30.846 --> 00:02:35.596 A:middle
that has just one property
which is a floating point number

00:02:35.816 --> 00:02:39.146 A:middle
of seconds relative
to our reference date.

00:02:39.706 --> 00:02:41.506 A:middle
So, basically it
just got one property

00:02:41.566 --> 00:02:45.426 A:middle
which is a double floating point
number, happens to be a double

00:02:45.426 --> 00:02:47.846 A:middle
in this case and
that's stores the number

00:02:47.846 --> 00:02:53.596 A:middle
of seconds either before or
after our reference date.

00:02:54.036 --> 00:02:57.046 A:middle
So, at this point I'm going
to introduce this graphic

00:02:57.046 --> 00:02:57.996 A:middle
which I'm going

00:02:57.996 --> 00:03:01.176 A:middle
to use throughout the
talk, this is our timeline.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:02:57.996 --> 00:03:01.176 A:middle
to use throughout the
talk, this is our timeline.

00:03:01.176 --> 00:03:04.856 A:middle
Now, I'm going to add a
boss here to the timeline,

00:03:04.856 --> 00:03:09.506 A:middle
this little knob in the middle
and that's going to refer

00:03:09.506 --> 00:03:11.556 A:middle
in this particular case
to our reference date.

00:03:12.246 --> 00:03:15.206 A:middle
So, we're a little bit after
our reference date right now

00:03:15.656 --> 00:03:16.956 A:middle
that the actual value

00:03:16.956 --> 00:03:18.936 A:middle
of the reference date
doesn't really matter,

00:03:19.526 --> 00:03:23.766 A:middle
it's in 2001 for-- in the
Gregorian calendar as it happens

00:03:23.766 --> 00:03:27.316 A:middle
so it's a little
ways in the past

00:03:27.556 --> 00:03:29.266 A:middle
but so the numbers right now

00:03:29.446 --> 00:03:34.226 A:middle
that an NSDate their
storing is a bit--

00:03:34.226 --> 00:03:35.716 A:middle
the numbers are positive.

00:03:36.146 --> 00:03:41.046 A:middle
We're about 12 years after 2001

00:03:41.146 --> 00:03:43.826 A:middle
and so the numbers
are slightly positive

00:03:43.826 --> 00:03:45.826 A:middle
but because this is a
floating point number.

00:03:45.826 --> 00:03:49.116 A:middle
These numbers cans be very large
and, you know, go often to the,

00:03:49.116 --> 00:03:54.736 A:middle
you know, far future and refer
to dates into the far past.

00:03:54.986 --> 00:03:59.786 A:middle
They're about, what, 31 million
seconds or so in every year

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:04:00.206 --> 00:04:04.396 A:middle
so of course after 12 years
there must be over, what,

00:04:04.666 --> 00:04:09.336 A:middle
360 million seconds that
are being as value seconds,

00:04:09.336 --> 00:04:11.956 A:middle
that are being stored in
every NSDate for dates

00:04:11.956 --> 00:04:13.266 A:middle
that around the current time.

00:04:14.296 --> 00:04:19.116 A:middle
So, these numbers are very large
of course and we don't work

00:04:19.116 --> 00:04:22.786 A:middle
with them numbers like
360 million seconds,

00:04:22.856 --> 00:04:26.406 A:middle
that's 2001 as humans and
I'll be getting to that

00:04:26.406 --> 00:04:28.276 A:middle
in a second what we do instead.

00:04:28.836 --> 00:04:31.386 A:middle
Now, in NSDate, I want

00:04:31.486 --> 00:04:34.836 A:middle
to emphasize represents
both a time and a date.

00:04:35.386 --> 00:04:37.726 A:middle
It has the word date
in there in the name

00:04:37.886 --> 00:04:40.316 A:middle
but since it is a
number of seconds

00:04:40.726 --> 00:04:45.456 A:middle
since the reference date, it
is both a date and a time.

00:04:45.456 --> 00:04:48.546 A:middle
It refers to a specific
moment in time really.

00:04:49.166 --> 00:04:54.076 A:middle
A typical thing you
might do with NSDate is

00:04:54.076 --> 00:04:58.886 A:middle
to get the current date, a date
object that represents now,

00:04:59.216 --> 00:05:02.266 A:middle
this very moment when I
making the method call.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:04:59.216 --> 00:05:02.266 A:middle
this very moment when I
making the method call.

00:05:02.756 --> 00:05:04.966 A:middle
And I'll be using this
a bunch in the talk

00:05:04.966 --> 00:05:07.296 A:middle
so that's why I'm putting
it up in the slide now.

00:05:08.086 --> 00:05:11.336 A:middle
To get the current time or
a date with the current date

00:05:11.336 --> 00:05:14.156 A:middle
in it you simply call
the class method Date.

00:05:14.156 --> 00:05:17.146 A:middle
It's very simple,
straight forward.

00:05:18.236 --> 00:05:20.316 A:middle
So, because these
numbers are very large,

00:05:20.316 --> 00:05:22.266 A:middle
of course like numbers
of seconds,

00:05:22.266 --> 00:05:24.866 A:middle
they are really cumbersome
for human to deal with.

00:05:24.976 --> 00:05:30.336 A:middle
And so, we as humans over time
have developed these notions

00:05:30.336 --> 00:05:35.476 A:middle
of what we call in this case
dateComponents that is years

00:05:35.476 --> 00:05:38.856 A:middle
and months and days and hours
and minutes and seconds.

00:05:38.856 --> 00:05:43.016 A:middle
We break time down into either,
you know, something that relates

00:05:43.016 --> 00:05:46.786 A:middle
to an astronomical cycle, or
something artificial like hours

00:05:46.786 --> 00:05:51.986 A:middle
and minutes and seconds which
are easier for us to deal with.

00:05:52.256 --> 00:05:57.136 A:middle
Now, an NSDateComponents is a
slide says here a simple model

00:05:57.136 --> 00:05:59.756 A:middle
object with stores these
kinds of components.

00:05:59.806 --> 00:06:03.016 A:middle
So, if I have NSDateComponents
object I can set it

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:05:59.806 --> 00:06:03.016 A:middle
So, if I have NSDateComponents
object I can set it

00:06:03.016 --> 00:06:05.206 A:middle
as month property
to 6 for example

00:06:05.206 --> 00:06:06.796 A:middle
or it's day property to 14.

00:06:07.756 --> 00:06:09.296 A:middle
Now, the other properties like--

00:06:09.726 --> 00:06:12.076 A:middle
well there's many other
properties, other properties

00:06:12.076 --> 00:06:15.096 A:middle
like hours and minutes
and seconds, or year

00:06:15.266 --> 00:06:19.846 A:middle
or what the weekday is
or those kinds of things.

00:06:20.126 --> 00:06:23.966 A:middle
I've not specified in this
date components object

00:06:24.446 --> 00:06:26.466 A:middle
of what happens with those.

00:06:26.916 --> 00:06:30.826 A:middle
Well, the default value for
every component is "unspecified"

00:06:31.376 --> 00:06:32.636 A:middle
with NSDateComponents.

00:06:32.636 --> 00:06:37.596 A:middle
So, unless a value has been set
it has this value, special value

00:06:37.996 --> 00:06:40.126 A:middle
which is basically
blank has not been set.

00:06:40.126 --> 00:06:44.586 A:middle
And there's a constant for that
NSDateComponentsUnspecified.

00:06:48.316 --> 00:06:49.896 A:middle
NSCalendars where most

00:06:49.896 --> 00:06:53.166 A:middle
of the calendar calculations
APIs occur.

00:06:54.016 --> 00:06:57.906 A:middle
NSCalendar is the object
that represents various kinds

00:06:57.906 --> 00:07:02.756 A:middle
of world calendars and knows
how to do calendar math on them.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:06:57.906 --> 00:07:02.756 A:middle
of world calendars and knows
how to do calendar math on them.

00:07:03.166 --> 00:07:06.906 A:middle
It knows how to take an NSDate
for example and break it

00:07:06.906 --> 00:07:09.786 A:middle
down into the components like
what is the year, what month

00:07:09.786 --> 00:07:12.246 A:middle
and day within a given calendar.

00:07:12.246 --> 00:07:15.516 A:middle
And the-- you know, various
kinds of calendars include

00:07:15.516 --> 00:07:17.276 A:middle
for example the Gregorian
calendar.

00:07:17.856 --> 00:07:20.376 A:middle
That's the calendar I'm mainly
going to be using in this talk

00:07:20.376 --> 00:07:22.236 A:middle
for some of my illustrations.

00:07:23.036 --> 00:07:27.426 A:middle
Here we see a calendar
showing January 2012.

00:07:28.556 --> 00:07:32.646 A:middle
But-- and the Gregorian
calendar is of course the--

00:07:32.646 --> 00:07:34.446 A:middle
a name for the what--

00:07:34.596 --> 00:07:36.936 A:middle
some people also call
the Western Calendar.

00:07:36.936 --> 00:07:41.146 A:middle
The calendar which is very
commonly used in commerce

00:07:41.146 --> 00:07:45.306 A:middle
for example around the world
even where a local calendar

00:07:45.306 --> 00:07:48.686 A:middle
like the Hebrew Calendar
or the Islamic Calendar,

00:07:49.036 --> 00:07:52.766 A:middle
or the Thai Buddhist
Calendar is being used instead

00:07:53.096 --> 00:07:56.096 A:middle
by the local people.

00:07:56.826 --> 00:08:01.336 A:middle
So, as I say, NSCalendar knows
how to convert between NSDates,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:07:56.826 --> 00:08:01.336 A:middle
So, as I say, NSCalendar knows
how to convert between NSDates,

00:08:01.436 --> 00:08:05.936 A:middle
these very large numbers
which are not specific

00:08:05.936 --> 00:08:07.286 A:middle
to any particular calendar.

00:08:07.796 --> 00:08:10.726 A:middle
And the components that
is the human components

00:08:11.186 --> 00:08:15.326 A:middle
that humans are using with
the specific calendar systems.

00:08:16.716 --> 00:08:21.436 A:middle
NSCalendar also contains various
calendar calculation APIs.

00:08:21.436 --> 00:08:23.076 A:middle
And we'll be looking
at some of those today.

00:08:23.756 --> 00:08:26.206 A:middle
And it has several
properties as well

00:08:26.206 --> 00:08:28.336 A:middle
to control the calculation
parameters.

00:08:28.336 --> 00:08:32.566 A:middle
For example, what is the
time zone that I want

00:08:32.566 --> 00:08:34.515 A:middle
to do the calculations in.

00:08:35.515 --> 00:08:42.916 A:middle
To-- a common calendar that
when why use is the what we call

00:08:42.916 --> 00:08:44.336 A:middle
the autoupdatingCalendar.

00:08:44.936 --> 00:08:48.196 A:middle
And here I've shown a
very simple example of how

00:08:48.196 --> 00:08:49.166 A:middle
to create one of those.

00:08:50.176 --> 00:08:55.586 A:middle
The user on the system
hasn't preferred calendar.

00:08:55.586 --> 00:08:57.826 A:middle
There's a setting for that
or preference for that.

00:08:58.616 --> 00:09:01.496 A:middle
If the user changes
their preferred calendar,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:08:58.616 --> 00:09:01.496 A:middle
If the user changes
their preferred calendar,

00:09:01.716 --> 00:09:03.886 A:middle
you may want your
application to update

00:09:04.116 --> 00:09:07.846 A:middle
to whatever the new
users preference is.

00:09:08.216 --> 00:09:12.196 A:middle
And so, this is-- what this does
is it returns a calendar object

00:09:12.546 --> 00:09:14.756 A:middle
which watches for changes

00:09:14.756 --> 00:09:18.596 A:middle
to the user's calendar
preference and updates itself.

00:09:18.646 --> 00:09:22.656 A:middle
So, you can use this and sort
of fire and forget if you will,

00:09:22.656 --> 00:09:27.156 A:middle
and not have to worry about
the user's calendar changing.

00:09:27.436 --> 00:09:29.136 A:middle
This thing will change itself

00:09:29.226 --> 00:09:32.426 A:middle
to match whatever the user's
setting is at any given point.

00:09:33.976 --> 00:09:37.996 A:middle
So, what are these calendar
calculations that you can do?

00:09:37.996 --> 00:09:39.826 A:middle
Well, there's many
different kinds of things

00:09:40.266 --> 00:09:41.746 A:middle
that why I'm want
to do but I'm going

00:09:41.746 --> 00:09:43.106 A:middle
to give a couple
of examples here.

00:09:43.426 --> 00:09:45.216 A:middle
So, here we are the
timeline again,

00:09:45.216 --> 00:09:48.736 A:middle
I've marked June
14th and August 26th.

00:09:49.356 --> 00:09:53.096 A:middle
And one might ask for example,
how many weeks are there

00:09:53.096 --> 00:09:54.886 A:middle
between these two dates?

00:09:55.486 --> 00:09:57.346 A:middle
Well, I know between-- strictly

00:09:57.346 --> 00:09:59.966 A:middle
between these two dates
there are 72 days.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:10:00.526 --> 00:10:04.756 A:middle
And since there's seven days
in a week, that's 10 weeks,

00:10:04.806 --> 00:10:07.366 A:middle
they're up to 10 weeks
plus two extra days

00:10:07.826 --> 00:10:09.346 A:middle
in between these two dates.

00:10:10.646 --> 00:10:12.986 A:middle
Another kind of calculation
one might do is

00:10:12.986 --> 00:10:14.656 A:middle
to ask questions about weeks.

00:10:15.126 --> 00:10:16.586 A:middle
Now, here I'm going
to show a graphic

00:10:17.416 --> 00:10:22.486 A:middle
where I've highlighted
today, June 14th.

00:10:23.686 --> 00:10:26.966 A:middle
But one thing you might notice
is for example if you're used

00:10:26.966 --> 00:10:30.926 A:middle
to United States Convention
of starting the calendars

00:10:31.216 --> 00:10:33.016 A:middle
with Sunday on the far left,

00:10:33.016 --> 00:10:34.446 A:middle
you might noticed
this is little odd.

00:10:34.846 --> 00:10:36.386 A:middle
I've chosen to start
this calendar

00:10:36.386 --> 00:10:37.796 A:middle
with Monday is the first day.

00:10:38.306 --> 00:10:41.086 A:middle
And so, I've just doing
this to highlight the fact

00:10:41.086 --> 00:10:46.236 A:middle
that different kinds of locales
might choose different first

00:10:46.236 --> 00:10:48.946 A:middle
days in the week or different
days of the week to be the--

00:10:49.086 --> 00:10:50.306 A:middle
their first day of the week.

00:10:50.736 --> 00:10:53.756 A:middle
This is a convention that you
might see for example more often

00:10:53.756 --> 00:10:56.406 A:middle
in Europe than here
in the United States.

00:10:57.446 --> 00:11:01.466 A:middle
So, one question I
might to ask is given

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:10:57.446 --> 00:11:01.466 A:middle
So, one question I
might to ask is given

00:11:01.466 --> 00:11:03.306 A:middle
that today is the 14th of June.

00:11:03.956 --> 00:11:06.766 A:middle
What is the week that
contains this date?

00:11:07.386 --> 00:11:09.106 A:middle
Well, here I've highlighted it.

00:11:09.426 --> 00:11:11.436 A:middle
June 10th was the
first day of the week

00:11:11.676 --> 00:11:14.606 A:middle
in this particular
locale of this calendar.

00:11:15.706 --> 00:11:21.906 A:middle
And the week extends
through the 16th.

00:11:21.906 --> 00:11:25.046 A:middle
NSTimeZone then I
mentioned time zones already.

00:11:25.536 --> 00:11:27.056 A:middle
NSTimeZone is our object

00:11:27.056 --> 00:11:29.366 A:middle
that represents these
time zone regions.

00:11:29.766 --> 00:11:33.116 A:middle
A time zone is the
geo-political region

00:11:33.306 --> 00:11:35.846 A:middle
like the one I've
highlighted here with Geneva,

00:11:35.846 --> 00:11:38.376 A:middle
Switzerland having
the blue dot over it.

00:11:39.346 --> 00:11:41.376 A:middle
It's a geo-political
region of the world

00:11:41.846 --> 00:11:46.636 A:middle
that has a particular
offset from Universal Time

00:11:47.136 --> 00:11:49.946 A:middle
and a particular set
of rules that determine

00:11:49.946 --> 00:11:51.596 A:middle
when that offset changes.

00:11:52.376 --> 00:11:54.296 A:middle
Generally, we call that
kind of thing for example

00:11:54.296 --> 00:11:56.876 A:middle
"daylight saving time"
or "summer time."

00:11:57.916 --> 00:12:00.376 A:middle
And you see it's a very
irregular region but, you know,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:11:57.916 --> 00:12:00.376 A:middle
And you see it's a very
irregular region but, you know,

00:12:00.786 --> 00:12:03.376 A:middle
I call it geo-political.

00:12:03.616 --> 00:12:06.586 A:middle
Geo meaning, you know,
related to the earth

00:12:06.786 --> 00:12:11.966 A:middle
and it is very much vertical
band of the earth which has more

00:12:11.966 --> 00:12:14.746 A:middle
or less the same
longitudes in it.

00:12:15.386 --> 00:12:19.286 A:middle
But also that word political
is important in geo-political

00:12:19.566 --> 00:12:24.596 A:middle
because each country within
a given longitude band could

00:12:24.866 --> 00:12:29.326 A:middle
of course decide on
its own that it has one

00:12:29.326 --> 00:12:32.466 A:middle
or another different set of
rules from other countries

00:12:32.906 --> 00:12:34.456 A:middle
within the same kind of band.

00:12:34.746 --> 00:12:37.406 A:middle
And it's NSTimeZone
that has to keep track

00:12:37.516 --> 00:12:40.796 A:middle
of all these different countries
rules about, for example,

00:12:41.086 --> 00:12:43.816 A:middle
when they go into daylight
saving time or summer time.

00:12:44.346 --> 00:12:46.776 A:middle
And when they come back
out-- back to standard time.

00:12:47.926 --> 00:12:52.376 A:middle
So, as I say NSTimeZone
is the object that knows

00:12:52.376 --> 00:12:55.656 A:middle
about the local offset
from Universal Time

00:12:55.956 --> 00:12:57.486 A:middle
and when that changes.

00:12:58.026 --> 00:13:00.246 A:middle
Now, very similar to NSCalendar,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:12:58.026 --> 00:13:00.246 A:middle
Now, very similar to NSCalendar,

00:13:01.486 --> 00:13:03.486 A:middle
you can create an
NSTimeZone object

00:13:03.806 --> 00:13:05.616 A:middle
which we call the
local time zone.

00:13:06.496 --> 00:13:10.466 A:middle
And this object will represent
whatever the current time zone

00:13:10.466 --> 00:13:13.516 A:middle
is that the user has set
on their computer system.

00:13:14.116 --> 00:13:16.096 A:middle
Or if the user has, you know,

00:13:16.096 --> 00:13:19.546 A:middle
requested that the time zone
changes the user moves around,

00:13:19.896 --> 00:13:22.256 A:middle
this object will
update itself based

00:13:22.256 --> 00:13:24.406 A:middle
on the user's location changes.

00:13:25.826 --> 00:13:29.376 A:middle
So, let's dive in now to
this Common Operations

00:13:29.496 --> 00:13:30.516 A:middle
that I want to talk about.

00:13:30.516 --> 00:13:33.746 A:middle
And I'm going to begin by
talking about midnight.

00:13:34.906 --> 00:13:38.046 A:middle
It's very common for
people to want to know

00:13:38.116 --> 00:13:40.816 A:middle
about midnight for
various reasons.

00:13:41.646 --> 00:13:44.566 A:middle
But midnight can be
a little problematic.

00:13:44.956 --> 00:13:46.916 A:middle
And that's why I have
midnight in quotes,

00:13:46.916 --> 00:13:49.166 A:middle
and you'll see why I
have midnight in quotes

00:13:49.586 --> 00:13:52.076 A:middle
in a few bullets here.

00:13:52.386 --> 00:13:55.206 A:middle
Well, first, why do
people want midnight?

00:13:55.626 --> 00:13:58.836 A:middle
Well, one common reason is
that people are using it

00:13:59.036 --> 00:14:02.196 A:middle
as a default "don't care" time.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:13:59.036 --> 00:14:02.196 A:middle
as a default "don't care" time.

00:14:02.746 --> 00:14:06.166 A:middle
It is-- they may want
to use an NSDate object

00:14:06.616 --> 00:14:07.876 A:middle
to represent a date.

00:14:08.336 --> 00:14:11.186 A:middle
For example, suppose they
want to use an NSDate object

00:14:11.186 --> 00:14:12.776 A:middle
to represents somebody's
birthday.

00:14:13.326 --> 00:14:17.976 A:middle
But they don't care about
the time part that of NSDate.

00:14:17.976 --> 00:14:20.456 A:middle
You know, generally,
we don't worry

00:14:20.456 --> 00:14:23.116 A:middle
about what time people are born

00:14:23.116 --> 00:14:27.786 A:middle
within that day unless you're
say calculating astrological

00:14:27.836 --> 00:14:29.196 A:middle
charts or something like that.

00:14:30.056 --> 00:14:34.206 A:middle
So, they say to themselves
the programmers says, "Well,

00:14:34.206 --> 00:14:35.646 A:middle
I want to use an NSDate

00:14:35.646 --> 00:14:38.296 A:middle
to represent this person's
birthday, but I don't care

00:14:38.296 --> 00:14:41.146 A:middle
about what time of day
it is, so I'm going to--

00:14:41.146 --> 00:14:43.626 A:middle
I went up the kind of tidy
about things so I'm going

00:14:43.626 --> 00:14:44.526 A:middle
to set that to midnight."

00:14:45.836 --> 00:14:50.056 A:middle
Well, what I would
suggest is when you need

00:14:50.056 --> 00:14:52.006 A:middle
to do this, use noon instead.

00:14:52.676 --> 00:14:55.946 A:middle
Midnight can be problematic as
I'll described but in a moment.

00:14:56.406 --> 00:15:01.066 A:middle
So, if you really don't care
about the time use noon instead.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:14:56.406 --> 00:15:01.066 A:middle
So, if you really don't care
about the time use noon instead.

00:15:01.736 --> 00:15:05.166 A:middle
The other main reason
that people want to it

00:15:05.166 --> 00:15:08.836 A:middle
over midnight is they want
to know when the day changes.

00:15:09.386 --> 00:15:13.716 A:middle
So, for example, they may want
to update the user interface

00:15:13.716 --> 00:15:18.216 A:middle
of the application when the day
changes from one day to the next

00:15:18.216 --> 00:15:20.126 A:middle
which is what midnight is,

00:15:20.126 --> 00:15:23.116 A:middle
the moment at which
the next day starts.

00:15:24.496 --> 00:15:26.206 A:middle
But midnight can be troublesome.

00:15:26.946 --> 00:15:33.146 A:middle
For example, in Brazil, the
Brazilian time zone changes

00:15:33.426 --> 00:15:37.586 A:middle
by jumping forward from
midnight to 1 a.m. when they go

00:15:37.586 --> 00:15:39.346 A:middle
into their summer time.

00:15:39.846 --> 00:15:43.986 A:middle
And then the reverse happens,
you know, in their fall.

00:15:44.376 --> 00:15:47.006 A:middle
So, there may not
exist a midnight.

00:15:47.776 --> 00:15:50.686 A:middle
When 11:59 and 59
seconds comes along

00:15:50.686 --> 00:15:53.796 A:middle
and in Brazil, midnight
is skipped.

00:15:54.046 --> 00:15:57.606 A:middle
And the first moment of that
day is 1 a.m. not midnight.

00:15:58.046 --> 00:16:00.816 A:middle
So, and then, of course,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:15:58.046 --> 00:16:00.816 A:middle
So, and then, of course,

00:16:00.816 --> 00:16:03.966 A:middle
if the reverse happens
there are two midnights then

00:16:03.966 --> 00:16:06.666 A:middle
when they go back in
the standard time.

00:16:07.166 --> 00:16:10.216 A:middle
So, if you're using
midnight to mean a special--

00:16:10.436 --> 00:16:14.346 A:middle
for some special reason, you
can get in trouble of course

00:16:14.346 --> 00:16:15.976 A:middle
because there may not exist one.

00:16:16.256 --> 00:16:20.776 A:middle
Instead I would you
encourage to think in terms

00:16:20.776 --> 00:16:22.346 A:middle
of the "start of a day."

00:16:22.516 --> 00:16:23.726 A:middle
When does the day start?

00:16:23.796 --> 00:16:27.556 A:middle
What is the range
of time of a day?

00:16:28.476 --> 00:16:31.306 A:middle
And so, how do you do--
go about calculating that?

00:16:31.876 --> 00:16:34.316 A:middle
Well, this is very
common operation we found.

00:16:34.756 --> 00:16:38.156 A:middle
So, we've now added an
operation to do that.

00:16:38.476 --> 00:16:42.546 A:middle
So, to calculate today's start
what I would now do nowadays

00:16:43.006 --> 00:16:45.496 A:middle
with this new API we've added is

00:16:45.496 --> 00:16:47.876 A:middle
to call the method
startOfDayForDate.

00:16:48.336 --> 00:16:51.086 A:middle
And here I'm passing
an NSDate date which is

00:16:51.086 --> 00:16:55.786 A:middle
of course the now date, the date
representing the current moment.

00:16:56.996 --> 00:17:00.876 A:middle
For-- and that would give me
of course today's start date.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:16:56.996 --> 00:17:00.876 A:middle
For-- and that would give me
of course today's start date.

00:17:01.146 --> 00:17:05.286 A:middle
For tomorrow's start date,
we need to do some more work.

00:17:05.646 --> 00:17:07.266 A:middle
Now, here in this
example I'm going

00:17:07.266 --> 00:17:09.776 A:middle
to be very robust
about my calculation.

00:17:09.976 --> 00:17:14.376 A:middle
So, first I'm going
to create the date

00:17:14.376 --> 00:17:17.816 A:middle
which is the startOfToday
and I do that again

00:17:17.816 --> 00:17:20.306 A:middle
with the same line of code.

00:17:20.726 --> 00:17:24.296 A:middle
Then I calculate a date
which is sometime in tomorrow

00:17:24.846 --> 00:17:29.396 A:middle
by using this method
dateByAddingUnit and passing

00:17:29.396 --> 00:17:32.976 A:middle
in the constant
NSCalendarUnitDay.

00:17:33.066 --> 00:17:37.756 A:middle
So, I'm going to add
one day to my start date

00:17:37.806 --> 00:17:40.726 A:middle
which was the previous line
here, the start of today.

00:17:41.746 --> 00:17:45.826 A:middle
And I'm not going to pass in
any options this particular case

00:17:46.686 --> 00:17:49.426 A:middle
and I have a date which
is sometime in tomorrow.

00:17:50.786 --> 00:17:55.396 A:middle
But, of course, if today's
start moment, if the--

00:17:55.486 --> 00:17:59.466 A:middle
first moment of the day was 1
a.m., well, that's not going

00:17:59.466 --> 00:18:03.116 A:middle
to be the same moment
that tomorrow

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:17:59.466 --> 00:18:03.116 A:middle
to be the same moment
that tomorrow

00:18:03.116 --> 00:18:05.316 A:middle
because of the daylight
saving time transition.

00:18:05.436 --> 00:18:09.656 A:middle
I mean that's not going to
the same start of the moment,

00:18:09.796 --> 00:18:13.406 A:middle
start of the day tomorrow.

00:18:13.406 --> 00:18:16.656 A:middle
So, I have to call
startOfDateForDay--

00:18:17.356 --> 00:18:21.336 A:middle
startOfDayForDate,
excuse me, again once more

00:18:21.876 --> 00:18:25.216 A:middle
to compute the real
start moment of tomorrow.

00:18:25.456 --> 00:18:29.316 A:middle
So, anyway, let's move on.

00:18:31.706 --> 00:18:35.136 A:middle
So, why does one want
to compute midnight?

00:18:35.136 --> 00:18:37.406 A:middle
Well, the second example
I gave was you want

00:18:37.596 --> 00:18:40.206 A:middle
to do some reaction to midnight.

00:18:40.286 --> 00:18:42.776 A:middle
You want to run some code
when midnight occurs.

00:18:43.026 --> 00:18:47.676 A:middle
So, we have a new notification
for that special case

00:18:47.676 --> 00:18:49.336 A:middle
that is so very common.

00:18:50.096 --> 00:18:51.526 A:middle
And so, now you can register

00:18:51.526 --> 00:18:54.696 A:middle
for the
NSCalendarDayChangeNotification.

00:18:55.866 --> 00:19:00.666 A:middle
And you'll-- your code will get
called when the day changes.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:18:55.866 --> 00:19:00.666 A:middle
And you'll-- your code will get
called when the day changes.

00:19:00.666 --> 00:19:04.066 A:middle
When midnight or, you
know, the first moment

00:19:04.066 --> 00:19:05.476 A:middle
of the next day occurs.

00:19:06.626 --> 00:19:08.666 A:middle
Why would one want to do that?

00:19:08.666 --> 00:19:11.206 A:middle
Well, maybe, you've
been awake at midnight

00:19:11.206 --> 00:19:15.436 A:middle
and had a mail application
open, and you've seen suddenly

00:19:15.436 --> 00:19:20.716 A:middle
at midnight it changes all of
the today strings in the UI

00:19:21.056 --> 00:19:24.126 A:middle
to yesterday for all
those mail messages.

00:19:25.706 --> 00:19:28.866 A:middle
Well, first thing I do to go

00:19:28.866 --> 00:19:31.456 A:middle
about doing this is
I use the local--

00:19:31.456 --> 00:19:32.916 A:middle
our local notification center

00:19:32.916 --> 00:19:36.276 A:middle
so I call the defaultCenter
method to get that.

00:19:36.616 --> 00:19:40.026 A:middle
I use the usual method
that addObserverForName

00:19:40.026 --> 00:19:43.566 A:middle
and I pass a name of
this new string constant

00:19:44.526 --> 00:19:46.336 A:middle
which represents
this notification.

00:19:46.826 --> 00:19:49.496 A:middle
There's no object or queue
that I'm going to specify

00:19:49.496 --> 00:19:50.816 A:middle
in this particular example.

00:19:50.816 --> 00:19:55.156 A:middle
And then I specify the block
of code that I want to execute

00:19:55.646 --> 00:19:57.806 A:middle
when this notification occurs.

00:19:58.116 --> 00:19:59.506 A:middle
So, it's fairly straightly
forward use

00:19:59.716 --> 00:20:01.906 A:middle
of NSNotificationCenter
in this case.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:19:59.716 --> 00:20:01.906 A:middle
of NSNotificationCenter
in this case.

00:20:04.546 --> 00:20:07.746 A:middle
Now, midnight of course
is a specific example

00:20:07.876 --> 00:20:09.656 A:middle
of wanting a specific time

00:20:09.656 --> 00:20:13.446 A:middle
but sometimes people want
different specific times

00:20:13.656 --> 00:20:14.976 A:middle
but within the same day.

00:20:15.116 --> 00:20:17.696 A:middle
So, how does one go
about setting a date

00:20:18.056 --> 00:20:21.896 A:middle
to a specific time
within that date?

00:20:22.036 --> 00:20:25.756 A:middle
Well, let's suppose we want
to calculate 11:30 today,

00:20:25.836 --> 00:20:28.786 A:middle
11:30 being the time at
which this talk started.

00:20:30.106 --> 00:20:32.816 A:middle
Well, let's suppose I
have a date which is

00:20:32.866 --> 00:20:36.196 A:middle
at point A there on the graphic.

00:20:37.176 --> 00:20:40.686 A:middle
So, that would be a date
which before at a time

00:20:41.116 --> 00:20:43.766 A:middle
within this date
which is before 11:30.

00:20:44.216 --> 00:20:47.186 A:middle
Obviously, I need to compute
a date which is in the future

00:20:47.186 --> 00:20:49.396 A:middle
at which pushes the
date forward in time.

00:20:50.016 --> 00:20:53.506 A:middle
But if the data object that I
start with is at say point B,

00:20:53.796 --> 00:20:56.646 A:middle
I need to pull the
date back to 11:30.

00:20:57.476 --> 00:20:59.636 A:middle
So, what do I do?

00:20:59.746 --> 00:21:02.766 A:middle
Well, right now,
we're after 11:30

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:20:59.746 --> 00:21:02.766 A:middle
Well, right now,
we're after 11:30

00:21:02.766 --> 00:21:04.706 A:middle
so we're more like
at point B here.

00:21:05.066 --> 00:21:09.376 A:middle
So, to compute 11:30 of
today I'm going to start

00:21:09.376 --> 00:21:13.346 A:middle
with the current moment and
use this new method called

00:21:13.346 --> 00:21:18.746 A:middle
dateBySettingHour and set that
to 11, minute set it to 30,

00:21:19.256 --> 00:21:22.526 A:middle
and second set it
to zero toDate.

00:21:23.556 --> 00:21:27.076 A:middle
And again, in this case
there are no options

00:21:27.076 --> 00:21:28.186 A:middle
that I'm going to specify.

00:21:28.616 --> 00:21:32.026 A:middle
And what I get is the
date object that I started

00:21:32.026 --> 00:21:35.386 A:middle
with which was the current
moment has moved either forwards

00:21:35.386 --> 00:21:39.136 A:middle
or backwards in order to
set it's time to 11:30.

00:21:39.666 --> 00:21:44.826 A:middle
Another kind of question
people like to ask is,

00:21:44.826 --> 00:21:46.836 A:middle
is this date in today?

00:21:48.356 --> 00:21:52.536 A:middle
Well, it's a good
questions and very common.

00:21:52.536 --> 00:21:56.076 A:middle
So, we added a new method
for that isDateInToday,

00:21:56.076 --> 00:21:57.536 A:middle
and this returns a Boolean.

00:21:58.176 --> 00:22:01.836 A:middle
Now, of course, we didn't
just add one method here,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:21:58.176 --> 00:22:01.836 A:middle
Now, of course, we didn't
just add one method here,

00:22:01.976 --> 00:22:05.726 A:middle
it's also interesting to know
about yesterday and tomorrow.

00:22:06.156 --> 00:22:08.106 A:middle
So, we added two
methods for that as well.

00:22:09.386 --> 00:22:12.686 A:middle
Now, an interesting thing
about this particular API is

00:22:12.686 --> 00:22:15.956 A:middle
that the answer is going
to change over time,

00:22:16.306 --> 00:22:20.696 A:middle
time marches forward,
and so, a date object

00:22:20.696 --> 00:22:24.826 A:middle
which represents a
time in today, well,

00:22:24.826 --> 00:22:28.706 A:middle
tomorrow it won't be a time
which is in today of course.

00:22:29.566 --> 00:22:34.676 A:middle
And so, this is an answer which
is in some sense very transient

00:22:34.676 --> 00:22:40.326 A:middle
so that's something to keep
in mind and think about.

00:22:40.326 --> 00:22:43.116 A:middle
Now, if you want
to compare dates,

00:22:43.916 --> 00:22:46.066 A:middle
we have some new API
for that as well.

00:22:47.516 --> 00:22:50.506 A:middle
NSDate itself has
a compare method.

00:22:50.846 --> 00:22:55.316 A:middle
But since NSDate is simply,
basically an object wrapper

00:22:55.466 --> 00:22:57.116 A:middle
around a floating point number.

00:22:57.536 --> 00:23:01.586 A:middle
The compare method of NSDate
is very literal when you talk

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:22:57.536 --> 00:23:01.586 A:middle
The compare method of NSDate
is very literal when you talk

00:23:01.586 --> 00:23:05.286 A:middle
about wanting to know is
equal kind of comparison.

00:23:06.036 --> 00:23:08.196 A:middle
It's very literal
[inaudible] comparison.

00:23:09.256 --> 00:23:13.866 A:middle
But often people want to know
more like, you know, is this--

00:23:13.866 --> 00:23:17.286 A:middle
are these two dates, you
know, within the same day

00:23:17.286 --> 00:23:18.456 A:middle
or within the same hour?

00:23:19.476 --> 00:23:22.496 A:middle
Well, asking a question
like I just asked

00:23:22.496 --> 00:23:26.786 A:middle
on the previous slides "Is this
date today" is really just a

00:23:26.786 --> 00:23:29.426 A:middle
special case of asking
if two dates,

00:23:29.946 --> 00:23:33.636 A:middle
a date representing the
current moment and, you know,

00:23:33.836 --> 00:23:36.996 A:middle
some other given day
that you want to compare

00:23:36.996 --> 00:23:38.956 A:middle
with are on the same day.

00:23:39.096 --> 00:23:42.066 A:middle
You know, is this
date in the same day

00:23:42.066 --> 00:23:45.346 A:middle
as a date representing
the current moment?

00:23:46.236 --> 00:23:48.116 A:middle
Well, we have a new
method for this.

00:23:48.796 --> 00:23:52.106 A:middle
This is the compared
date toDate method.

00:23:52.106 --> 00:23:54.236 A:middle
You pass in the toDates
of interest.

00:23:54.946 --> 00:23:58.566 A:middle
And then as the last
parameter toUnitGranularity,

00:23:58.936 --> 00:24:03.646 A:middle
you pass in one of the
NSCalendarConstants for the unit

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:23:58.936 --> 00:24:03.646 A:middle
you pass in one of the
NSCalendarConstants for the unit

00:24:03.686 --> 00:24:04.636 A:middle
that you're interested in.

00:24:05.146 --> 00:24:07.266 A:middle
So, in this case I'm
going to ask the question,

00:24:07.266 --> 00:24:09.546 A:middle
are these two dates
in the same day?

00:24:09.916 --> 00:24:13.566 A:middle
But I could ask are these two
dates in the same month or year

00:24:13.936 --> 00:24:16.596 A:middle
or minute or what have you.

00:24:17.346 --> 00:24:21.506 A:middle
Now, and then, of course, if
the result is NSOrder the same

00:24:21.906 --> 00:24:25.756 A:middle
that really means that
they are in the same day.

00:24:26.186 --> 00:24:30.406 A:middle
Now, it's important to note that
this is not the same as asking

00:24:30.406 --> 00:24:34.956 A:middle
if toDates are within some
amount of one another.

00:24:35.706 --> 00:24:39.156 A:middle
So, toDates for example
can be on the same day

00:24:39.156 --> 00:24:45.896 A:middle
but they can be 23 hours and
59 minutes, sorry, apart.

00:24:46.276 --> 00:24:50.756 A:middle
But at the same time, toDates
can be just one second apart

00:24:50.756 --> 00:24:54.066 A:middle
but be on two different
days within,

00:24:54.136 --> 00:24:55.306 A:middle
you know, some given calendar.

00:24:56.186 --> 00:24:59.736 A:middle
And so, this is not the same--
I want to point out as asking

00:24:59.736 --> 00:25:05.136 A:middle
if toDates are close to one
another, but rather if they're

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:24:59.736 --> 00:25:05.136 A:middle
if toDates are close to one
another, but rather if they're

00:25:05.136 --> 00:25:08.416 A:middle
on the same-- within
the same calendar unit

00:25:08.846 --> 00:25:10.956 A:middle
within the given calendar
that you're using.

00:25:11.546 --> 00:25:18.626 A:middle
Another thing people tend to do
with NSDate objects is they want

00:25:18.626 --> 00:25:21.426 A:middle
to treat them as
timeless entities,

00:25:21.426 --> 00:25:23.346 A:middle
so I call this "Timeless Dates."

00:25:23.916 --> 00:25:27.196 A:middle
Just like in my birthday
example earlier, you don't care

00:25:27.196 --> 00:25:30.786 A:middle
about the time component, you
just want to use an NSDate

00:25:30.786 --> 00:25:36.676 A:middle
to store a date, a year and a
month and a day essentially.

00:25:37.386 --> 00:25:43.006 A:middle
But NSDates are here to store
the number of seconds relative

00:25:43.056 --> 00:25:44.106 A:middle
to our reference date.

00:25:44.576 --> 00:25:49.416 A:middle
So, they don't simply store
values like Era, Year,

00:25:49.676 --> 00:25:55.456 A:middle
Month and Day which you might
want to simply store yourself.

00:25:57.046 --> 00:25:59.136 A:middle
In those cases I
would suggest using an

00:25:59.176 --> 00:26:00.696 A:middle
NSDateComponents object.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:25:59.176 --> 00:26:00.696 A:middle
NSDateComponents object.

00:26:01.256 --> 00:26:04.736 A:middle
An NSDateComponents object as I
said is very simple model object

00:26:04.736 --> 00:26:09.606 A:middle
that has separate properties for
each of the calendar components.

00:26:10.056 --> 00:26:12.136 A:middle
And so, it's very
straightforward to use one

00:26:12.726 --> 00:26:15.366 A:middle
in this way, just to store
say something like a birthday

00:26:15.366 --> 00:26:18.736 A:middle
where you just a have a
year and a month and a day.

00:26:19.136 --> 00:26:21.936 A:middle
Or, of course, another
approach would be

00:26:22.156 --> 00:26:24.316 A:middle
to create your own
simple model object

00:26:24.706 --> 00:26:29.796 A:middle
with just three integers say
or four integers if you want

00:26:29.796 --> 00:26:32.116 A:middle
to also start the Era.

00:26:32.596 --> 00:26:35.896 A:middle
And, you know, if you use
the app property syntax

00:26:35.896 --> 00:26:39.046 A:middle
in Objective-C the compiler
will create the setter

00:26:39.046 --> 00:26:41.216 A:middle
and the getter methods for you.

00:26:42.766 --> 00:26:45.266 A:middle
Now, you need-- if you do
this you need to remember

00:26:45.266 --> 00:26:49.376 A:middle
to include a property in
this object for the calendar

00:26:50.146 --> 00:26:53.756 A:middle
that these components
are relative too.

00:26:54.136 --> 00:26:57.566 A:middle
You know, a year number, a
month number, a day number,

00:26:57.826 --> 00:26:59.126 A:middle
these are just integers.

00:26:59.556 --> 00:27:05.346 A:middle
They have no meaning outside
of the context of a calendar.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:26:59.556 --> 00:27:05.346 A:middle
They have no meaning outside
of the context of a calendar.

00:27:05.466 --> 00:27:07.656 A:middle
You know, what calendar
is that year in?

00:27:08.276 --> 00:27:12.656 A:middle
Well, for example, I can be
talking about the year 1434.

00:27:13.956 --> 00:27:15.586 A:middle
And if you assume
that I'm talking

00:27:15.586 --> 00:27:18.026 A:middle
about the Gregorian calendar,
you say, "Oh, he was talking

00:27:18.026 --> 00:27:21.136 A:middle
about a time 600
years in the past."

00:27:22.236 --> 00:27:25.276 A:middle
But instead I'm talking
about the Islamic calendar

00:27:25.276 --> 00:27:26.386 A:middle
and that's the current year.

00:27:27.366 --> 00:27:34.276 A:middle
So, you have to have some notion
of what calendar any given set

00:27:34.276 --> 00:27:36.426 A:middle
of components are related to.

00:27:36.786 --> 00:27:40.536 A:middle
So, one approach is to include
a property for the calendar,

00:27:40.536 --> 00:27:44.756 A:middle
you use to break a date
down into those components.

00:27:45.386 --> 00:27:51.956 A:middle
Or you can define the calendar
for that class of model object

00:27:52.166 --> 00:27:53.696 A:middle
to always be a fixed value.

00:27:53.696 --> 00:27:56.376 A:middle
You can say, "Well, these
are always Gregorian dates

00:27:56.376 --> 00:28:00.806 A:middle
or these are always dates in
the Japanese Imperial calendar."

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:27:56.376 --> 00:28:00.806 A:middle
or these are always dates in
the Japanese Imperial calendar."

00:28:02.606 --> 00:28:07.836 A:middle
But when you do that, remember;
do not use the user's calendar

00:28:08.206 --> 00:28:09.816 A:middle
as the fixed calendar.

00:28:09.816 --> 00:28:12.356 A:middle
The user's calendar
is not a fixed value.

00:28:12.356 --> 00:28:14.096 A:middle
The user can change
that setting.

00:28:14.646 --> 00:28:17.356 A:middle
And so if you say, Well, if
you use the user's calendar

00:28:17.356 --> 00:28:19.606 A:middle
and breakdown a date
and given a set

00:28:19.606 --> 00:28:22.156 A:middle
of components are
store some information

00:28:22.156 --> 00:28:25.816 A:middle
that the user input
like the year 1434.

00:28:26.706 --> 00:28:28.996 A:middle
And then later the user
changes their calendar.

00:28:29.576 --> 00:28:35.326 A:middle
Well, now you've lost some
information because in

00:28:35.326 --> 00:28:39.026 A:middle
that year 1434 is not
necessarily the same year,

00:28:39.026 --> 00:28:43.756 A:middle
you know, it's the same
real value as would exist

00:28:43.756 --> 00:28:46.056 A:middle
in the user's new
preferred calendar.

00:28:46.406 --> 00:28:48.306 A:middle
So, do not use the
user's calendar

00:28:49.146 --> 00:28:51.606 A:middle
as a fixed calendar value.

00:28:51.986 --> 00:28:57.256 A:middle
Now, the same discussion here
applies to dateless times.

00:28:57.666 --> 00:29:00.936 A:middle
Sometimes people use
NSDate objects or try

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:28:57.666 --> 00:29:00.936 A:middle
Sometimes people use
NSDate objects or try

00:29:00.936 --> 00:29:04.466 A:middle
to use NSDate objects
to represent times

00:29:04.466 --> 00:29:06.496 A:middle
like 11:30 in the morning.

00:29:07.296 --> 00:29:10.826 A:middle
And they don't want to-- they
don't need or want to deal

00:29:10.826 --> 00:29:12.736 A:middle
with any of the higher
components

00:29:12.736 --> 00:29:13.896 A:middle
like year, month and day.

00:29:13.896 --> 00:29:16.626 A:middle
They want to use NSDate
for whatever reason

00:29:16.626 --> 00:29:20.416 A:middle
but they don't need those
higher level components.

00:29:21.756 --> 00:29:23.246 A:middle
Well, the same discussion
applies.

00:29:23.246 --> 00:29:26.666 A:middle
Use an NSDateComponents object
instead would be my suggestion

00:29:27.056 --> 00:29:29.706 A:middle
or create your own
simple model object.

00:29:30.146 --> 00:29:37.536 A:middle
Now, the bulk of the talk
here is as I wrap up is going

00:29:37.536 --> 00:29:40.806 A:middle
to focus on finding
the next matching date.

00:29:42.106 --> 00:29:48.256 A:middle
Many kinds of calendar
calculations we found can be

00:29:48.336 --> 00:29:52.486 A:middle
thought of in terms of or
expressed as the question,

00:29:52.966 --> 00:29:54.986 A:middle
"What is the next date

00:29:55.456 --> 00:29:57.966 A:middle
which matches a given
set of criteria?"

00:29:59.266 --> 00:30:01.806 A:middle
So, we've added a
new API for that.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:29:59.266 --> 00:30:01.806 A:middle
So, we've added a
new API for that.

00:30:01.806 --> 00:30:04.216 A:middle
And this is perhaps
the most significant

00:30:04.646 --> 00:30:08.116 A:middle
of the new APIs we've added.

00:30:08.496 --> 00:30:12.586 A:middle
So, one thing-- one
question one might ask is

00:30:13.136 --> 00:30:14.206 A:middle
when is the next 10 a.m.?

00:30:14.206 --> 00:30:17.116 A:middle
You know, suppose I'm an
alarm clock application

00:30:17.166 --> 00:30:19.876 A:middle
and the user says, "Why do
I want to alarm at 10 a.m.?"

00:30:20.606 --> 00:30:22.096 A:middle
Well, the alarm clock
wants to know, well,

00:30:22.096 --> 00:30:24.696 A:middle
when is the next 10 a.m.
so they can fire the alarm.

00:30:25.886 --> 00:30:28.596 A:middle
Or the application might
want to know, well,

00:30:28.596 --> 00:30:29.966 A:middle
"When is the next Wednesday?"

00:30:30.416 --> 00:30:33.606 A:middle
Maybe the user has a meeting on
Wednesdays so they need to know

00:30:33.606 --> 00:30:36.356 A:middle
when is the next
Wednesday or you could ask

00:30:36.786 --> 00:30:39.536 A:middle
when is the next Wednesday
at 10 a.m. and so on.

00:30:39.536 --> 00:30:42.226 A:middle
I mean you can-- it fully
specifies a set of components

00:30:42.226 --> 00:30:46.856 A:middle
and I'll get into an
example of this in a minute.

00:30:47.366 --> 00:30:51.156 A:middle
And you ask the question, "Well,
give me the next occurrence

00:30:51.156 --> 00:30:53.246 A:middle
of this particular time
that I've specified."

00:30:54.336 --> 00:30:57.956 A:middle
So, here's one of the methods
that we've added to do this.

00:30:57.956 --> 00:30:59.396 A:middle
This is one of the simpler ones.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:31:00.186 --> 00:31:04.676 A:middle
The nextDateAfterDate
method, matchingComponents,

00:31:04.926 --> 00:31:10.896 A:middle
options method I should say
takes a date object at which

00:31:10.896 --> 00:31:13.506 A:middle
to begin searching and
always finds an answer

00:31:13.506 --> 00:31:16.066 A:middle
which is strictly
after that date.

00:31:17.306 --> 00:31:22.096 A:middle
For the second parameter
you pass in the components

00:31:22.286 --> 00:31:24.156 A:middle
which match are to be matched.

00:31:24.496 --> 00:31:26.756 A:middle
Now, these are the
literal values.

00:31:27.626 --> 00:31:30.116 A:middle
This isn't a method
for doing sort

00:31:30.116 --> 00:31:33.196 A:middle
of arbitrary Boolean
calculations of, you know,

00:31:33.756 --> 00:31:37.216 A:middle
give me the next date where
the hour is less than 11

00:31:37.276 --> 00:31:42.476 A:middle
and the weekday is greater than
Thursday and it's a full moon.

00:31:42.696 --> 00:31:45.056 A:middle
This is-is not an API for that.

00:31:45.676 --> 00:31:47.786 A:middle
You pass in the literal
set of components

00:31:47.946 --> 00:31:49.596 A:middle
that the date should match.

00:31:49.826 --> 00:31:52.116 A:middle
But of course it doesn't have to
be complete set of components.

00:31:52.116 --> 00:31:55.006 A:middle
You don't have to specify
every component like year,

00:31:55.006 --> 00:31:56.056 A:middle
month and day and so on.

00:31:56.056 --> 00:31:59.756 A:middle
You can just say, "I want,
you know, the next 11:30 a.m."

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:32:00.056 --> 00:32:00.666 A:middle
for example.

00:32:00.886 --> 00:32:06.066 A:middle
And then you pass in as the
third argument various options.

00:32:08.396 --> 00:32:10.516 A:middle
So, let's look at this example.

00:32:10.646 --> 00:32:14.476 A:middle
I want to find the next
Wednesday at 10 a.m. So,

00:32:14.476 --> 00:32:19.046 A:middle
I create a blank or empty
NSDateComponents object

00:32:19.946 --> 00:32:22.586 A:middle
and I set two properties on it.

00:32:22.786 --> 00:32:28.346 A:middle
I set the weekday, four happens
to be the constant for Wednesday

00:32:29.006 --> 00:32:31.886 A:middle
and I set the hour to
10 for 10 a.m. Now,

00:32:32.276 --> 00:32:34.686 A:middle
of course in your
real application

00:32:34.686 --> 00:32:36.466 A:middle
and your real program,
you're not going

00:32:36.466 --> 00:32:40.166 A:middle
to have numbers right
there like 4 and 10.

00:32:40.166 --> 00:32:43.976 A:middle
You're going to have numbers
or values which you've gotten

00:32:43.976 --> 00:32:46.486 A:middle
from the user or you've
gotten from a database,

00:32:46.486 --> 00:32:49.236 A:middle
or you've gotten over
the network from--

00:32:49.236 --> 00:32:52.066 A:middle
some JSON you've parsed or
whatever it happens to be.

00:32:52.396 --> 00:32:54.556 A:middle
But for the purposes of
this particular example

00:32:54.556 --> 00:32:56.766 A:middle
to keep things a little
simpler I'm going to ignore

00:32:56.766 --> 00:32:58.296 A:middle
where these numbers came from

00:32:58.716 --> 00:33:02.616 A:middle
and just literally expose
them here on my slides.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:32:58.716 --> 00:33:02.616 A:middle
and just literally expose
them here on my slides.

00:33:03.146 --> 00:33:06.856 A:middle
So, then I call the
method nextDateAfterDate.

00:33:06.856 --> 00:33:10.256 A:middle
I pass in NSDate date which
is the current moment.

00:33:10.256 --> 00:33:11.686 A:middle
I want to start searching now.

00:33:12.966 --> 00:33:16.056 A:middle
I passed in the dateComponents
that I just initialized.

00:33:16.546 --> 00:33:20.466 A:middle
And I passed in some options and
I'm going to ignore the question

00:33:20.466 --> 00:33:23.176 A:middle
of options for several
slides here

00:33:23.456 --> 00:33:27.526 A:middle
but I promise I will
get back to those.

00:33:27.746 --> 00:33:32.116 A:middle
Now, the question
arises what happens

00:33:32.116 --> 00:33:34.426 A:middle
to these other components
that I didn't specify?

00:33:34.426 --> 00:33:36.126 A:middle
What is the algorithm do?

00:33:36.126 --> 00:33:37.966 A:middle
You know, I didn't say
what min that I want

00:33:37.966 --> 00:33:40.806 A:middle
and I didn't say
what month I wanted.

00:33:41.586 --> 00:33:46.046 A:middle
Well, those of course as I
said towards the beginning

00:33:46.256 --> 00:33:48.806 A:middle
in an NSDateComponents
simply have a value

00:33:48.836 --> 00:33:50.876 A:middle
of NSDateComponents
and specified.

00:33:51.776 --> 00:33:53.736 A:middle
Well, that doesn't tell
us what the algorithm does

00:33:53.736 --> 00:33:55.966 A:middle
with those values, it tells
us what the values are.

00:33:57.306 --> 00:34:00.696 A:middle
For the lower components that
is the smaller components

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:33:57.306 --> 00:34:00.696 A:middle
For the lower components that
is the smaller components

00:34:00.696 --> 00:34:01.186 A:middle
if you will.

00:34:02.276 --> 00:34:07.086 A:middle
The smaller cycles
that are unspecified,

00:34:07.946 --> 00:34:12.626 A:middle
what the algorithm does is
basically assume the first

00:34:12.626 --> 00:34:15.416 A:middle
or the lowest value of
that cycle can take on.

00:34:15.835 --> 00:34:19.136 A:middle
In the case of minute or second
the lowest value is zero.

00:34:20.255 --> 00:34:23.416 A:middle
So, and this of course
is easy to understand.

00:34:23.416 --> 00:34:25.496 A:middle
If I'm searching forward in time

00:34:25.846 --> 00:34:30.485 A:middle
for the next 10 a.m. the first
moment within any 10 a.m.

00:34:30.485 --> 00:34:33.766 A:middle
that I'm going to find is the
moment which has minute zero

00:34:33.766 --> 00:34:37.746 A:middle
and second zero of course.

00:34:38.786 --> 00:34:42.176 A:middle
So, what happens for
the larger components?

00:34:42.966 --> 00:34:45.985 A:middle
Let's suppose we look at
the weekOfYear component.

00:34:45.985 --> 00:34:50.985 A:middle
Well, what we do in this
algorithm is we match the same

00:34:50.985 --> 00:34:55.255 A:middle
value that the date that you
passed in, that after date,

00:34:55.626 --> 00:34:57.446 A:middle
the data which to
begin searching.

00:34:58.036 --> 00:35:02.846 A:middle
We take its value of that
component and we look for either

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:34:58.036 --> 00:35:02.846 A:middle
We take its value of that
component and we look for either

00:35:02.896 --> 00:35:07.716 A:middle
that same value or the next
occurrence of that value.

00:35:08.356 --> 00:35:09.696 A:middle
Now, that's a little
complicated.

00:35:09.696 --> 00:35:11.446 A:middle
So, let me explain
with the graphic.

00:35:12.776 --> 00:35:16.116 A:middle
So, here's our June 14th again.

00:35:17.556 --> 00:35:19.486 A:middle
And suppose we're searching as--

00:35:20.026 --> 00:35:24.846 A:middle
in this example for the next
Wednesday at 10 a.m. Well,

00:35:24.846 --> 00:35:27.016 A:middle
the largest component
I specified

00:35:27.426 --> 00:35:30.176 A:middle
in my question was the
weekday, Wednesday.

00:35:31.226 --> 00:35:33.456 A:middle
So, we're going to search
within the same week

00:35:34.056 --> 00:35:38.816 A:middle
as today is 'cause I passed
in today the current moment

00:35:39.286 --> 00:35:42.746 A:middle
as my start date
to begin searching.

00:35:43.566 --> 00:35:44.566 A:middle
And we're going to search

00:35:44.566 --> 00:35:47.696 A:middle
in this week then
and the next week.

00:35:48.246 --> 00:35:50.976 A:middle
So, this is the range of
time we're going to search.

00:35:51.716 --> 00:35:56.116 A:middle
So, I ask for weekday as the
largest component I asked for.

00:35:56.716 --> 00:35:59.486 A:middle
The larger cycle,
the next larger cycle

00:35:59.486 --> 00:36:00.726 A:middle
that is of course the week.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:35:59.486 --> 00:36:00.726 A:middle
that is of course the week.

00:36:01.106 --> 00:36:05.296 A:middle
The weekday cycle around
repeat one after the other

00:36:05.916 --> 00:36:07.486 A:middle
within the cycle of week.

00:36:08.276 --> 00:36:12.956 A:middle
And so, we begin looking in this
week but after the date I passed

00:36:12.956 --> 00:36:16.496 A:middle
in which is the current moment
and we look in the next week.

00:36:17.746 --> 00:36:21.466 A:middle
Now, of course if the start date
that I pass in is at the end

00:36:21.466 --> 00:36:26.106 A:middle
of the year or the end of the
month or the end of the year

00:36:26.106 --> 00:36:30.046 A:middle
that next week that
we're willing to search

00:36:30.086 --> 00:36:33.706 A:middle
in for an answer might
be in the next month,

00:36:33.706 --> 00:36:35.486 A:middle
it might be in the
next year even.

00:36:35.716 --> 00:36:37.786 A:middle
So, we have to do the
same kind of treatment

00:36:37.816 --> 00:36:39.516 A:middle
for all the larger components.

00:36:40.646 --> 00:36:42.966 A:middle
Now, this is the default
behavior of the algorithm.

00:36:42.966 --> 00:36:48.166 A:middle
We only search in a sense a
little ways forward in time

00:36:48.476 --> 00:36:51.616 A:middle
and find you some
answer for that.

00:36:51.616 --> 00:36:59.396 A:middle
And this-- I'm going to give an
example in several slides here

00:36:59.396 --> 00:37:01.196 A:middle
which will make this
clear why we do this

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:36:59.396 --> 00:37:01.196 A:middle
which will make this
clear why we do this

00:37:01.256 --> 00:37:04.366 A:middle
but this the default
behavior and there's an option

00:37:04.366 --> 00:37:05.976 A:middle
for changing this
default behavior.

00:37:06.506 --> 00:37:10.636 A:middle
Let's go back to an example
I had early in the talk

00:37:10.636 --> 00:37:12.996 A:middle
which was Finding
Tomorrow's "Midnight."

00:37:13.186 --> 00:37:16.266 A:middle
Now, that took several lines
of code in the previous example

00:37:16.726 --> 00:37:23.116 A:middle
but I can rephrase that
question as one of finding.

00:37:23.626 --> 00:37:25.536 A:middle
So, I'm going to
use this new API,

00:37:26.556 --> 00:37:29.196 A:middle
create an empty NSDateComponents
object

00:37:29.536 --> 00:37:32.546 A:middle
and simply specify
the hour to be zero.

00:37:33.776 --> 00:37:36.786 A:middle
So, what this is going to do is
the algorithm is going to begin

00:37:36.786 --> 00:37:38.986 A:middle
at the date that
I'm going to give it

00:37:39.256 --> 00:37:40.836 A:middle
which is the current
moment here.

00:37:42.196 --> 00:37:44.576 A:middle
And it's going to search
forward for the next case

00:37:44.576 --> 00:37:47.056 A:middle
where a date is-- the date is

00:37:47.656 --> 00:37:50.296 A:middle
or has maybe I should
say the hour 0.

00:37:51.356 --> 00:37:55.446 A:middle
So, I pass in the dateComponents
and again I pass in some options

00:37:55.486 --> 00:37:58.566 A:middle
which I'm going to skip
over for the moment

00:37:58.566 --> 00:38:00.836 A:middle
but I promise I will
get back to those.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:37:58.566 --> 00:38:00.836 A:middle
but I promise I will
get back to those.

00:38:01.386 --> 00:38:05.306 A:middle
Now, it's possible that
there's no possible results.

00:38:05.696 --> 00:38:09.736 A:middle
For example, let's suppose
I initialized the day field

00:38:09.736 --> 00:38:11.456 A:middle
of my dateComponents to 50.

00:38:12.766 --> 00:38:15.326 A:middle
Well, there's no calendar
at least that I'm aware

00:38:15.326 --> 00:38:19.296 A:middle
of that has a day 50
in any of its months.

00:38:20.206 --> 00:38:22.616 A:middle
And so, if I call
the API then passing

00:38:22.616 --> 00:38:25.336 A:middle
that in what I'll
get is you know,

00:38:25.726 --> 00:38:29.916 A:middle
it's just an unreasonable
request in one sense to ask

00:38:29.916 --> 00:38:33.196 A:middle
for the next day which is 50.

00:38:34.096 --> 00:38:37.146 A:middle
So, what are these options
that I've been referring to

00:38:37.146 --> 00:38:38.446 A:middle
but I'm not explaining.

00:38:39.996 --> 00:38:41.666 A:middle
Well, I talked about
the default behavior

00:38:41.666 --> 00:38:44.506 A:middle
where we only search a
little ways forward in time.

00:38:44.506 --> 00:38:46.606 A:middle
We only search the
next occurrence

00:38:46.686 --> 00:38:52.606 A:middle
of the next larger cycle
if you will for an answer.

00:38:53.286 --> 00:38:55.636 A:middle
But if you need us
to search farther,

00:38:55.976 --> 00:38:58.626 A:middle
there's this option
NSCalendarMatchStrictly.

00:38:59.556 --> 00:39:03.086 A:middle
An example would be suppose you
wanted to find the next leap day

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:38:59.556 --> 00:39:03.086 A:middle
An example would be suppose you
wanted to find the next leap day

00:39:03.156 --> 00:39:04.376 A:middle
in the Gregorian calendar.

00:39:04.376 --> 00:39:06.416 A:middle
You want to find the
next February 29th.

00:39:07.126 --> 00:39:10.116 A:middle
Well, that could be as much
as four years in the future.

00:39:10.606 --> 00:39:13.516 A:middle
So, you need us to search
more than the current year

00:39:13.756 --> 00:39:15.566 A:middle
and the next year
for this answer.

00:39:15.886 --> 00:39:17.416 A:middle
You need to-- you
might need to search

00:39:17.416 --> 00:39:18.716 A:middle
up to four years in the future.

00:39:19.686 --> 00:39:22.196 A:middle
And so, that is the case
where you would need to pass

00:39:22.196 --> 00:39:24.466 A:middle
in this option match strictly.

00:39:25.156 --> 00:39:31.076 A:middle
Another example which I'll get
to in a minute is what happens

00:39:31.076 --> 00:39:33.276 A:middle
when a time doesn't exist

00:39:33.336 --> 00:39:35.526 A:middle
because of a daylight
savings time transition.

00:39:36.046 --> 00:39:39.536 A:middle
And again, this option has a
behavior, there in that kind

00:39:39.536 --> 00:39:42.696 A:middle
of case and I'll talk
about that in a second.

00:39:42.986 --> 00:39:45.206 A:middle
You might also want to
search backwards in times.

00:39:45.206 --> 00:39:46.686 A:middle
So, instead of just
searching forwards

00:39:46.686 --> 00:39:49.426 A:middle
for the next occurrence
even though that's common

00:39:49.426 --> 00:39:53.826 A:middle
for calendar or alarm
clock kinds of applications

00:39:53.826 --> 00:39:57.986 A:middle
in that kind of thing but you
also might want to go backwards

00:39:57.986 --> 00:39:59.436 A:middle
and so there's an
option for that.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:40:00.916 --> 00:40:05.796 A:middle
Then there are three
options for what to do,

00:40:06.096 --> 00:40:09.616 A:middle
what the algorithm should do
when the time is missing--

00:40:09.616 --> 00:40:12.756 A:middle
when there is no time
that matches that.

00:40:13.226 --> 00:40:14.206 A:middle
Now, I'm going to explain--

00:40:14.286 --> 00:40:16.816 A:middle
I'm going to dive in to
this particular example

00:40:17.226 --> 00:40:18.346 A:middle
in the next several slides.

00:40:18.346 --> 00:40:21.126 A:middle
So, I'm going to skip over
these options for the moment.

00:40:22.216 --> 00:40:23.956 A:middle
If there are multiple matches

00:40:24.176 --> 00:40:26.516 A:middle
such as there are
multiple 1:00 AM's

00:40:26.566 --> 00:40:30.606 A:middle
because Daylight Saving Time
transition has caused time

00:40:30.606 --> 00:40:34.646 A:middle
to jump backward and there are
happen to be two 1:00 AM's.

00:40:35.386 --> 00:40:38.876 A:middle
Well, there are two
options for you to tell us

00:40:39.026 --> 00:40:43.536 A:middle
which of those two options
or two alternatives you want.

00:40:44.956 --> 00:40:48.616 A:middle
NSCalendarMatchFirst is the
default option so you don't need

00:40:48.616 --> 00:40:53.476 A:middle
to specify that one if you want
the first 1:00 a.m. for example.

00:40:54.956 --> 00:40:58.316 A:middle
Now, one of these four
options is required

00:40:58.786 --> 00:41:00.416 A:middle
or will raise an exception.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:40:58.786 --> 00:41:00.416 A:middle
or will raise an exception.

00:41:00.846 --> 00:41:06.066 A:middle
You either need to ask for
strict matching or you need

00:41:06.066 --> 00:41:08.786 A:middle
to pass in one of the options
that tell us what to do

00:41:09.096 --> 00:41:13.556 A:middle
when the most desirable
time is actually missing.

00:41:14.636 --> 00:41:17.916 A:middle
So, let's look an
extended example, really,

00:41:18.316 --> 00:41:23.716 A:middle
where we're looking for the next
2:30 a.m. In the United States,

00:41:23.986 --> 00:41:26.146 A:middle
the Daylight Saving
Time transition

00:41:26.696 --> 00:41:30.176 A:middle
in the spring skips
the 2:00 hour.

00:41:31.286 --> 00:41:32.556 A:middle
And so, what does
that look like?

00:41:32.556 --> 00:41:34.386 A:middle
Well, here's our timeline again.

00:41:34.916 --> 00:41:39.616 A:middle
So, midnight of the Daylight
Saving Time transition day comes

00:41:39.616 --> 00:41:42.596 A:middle
along, time passes
and we have 1:00 a.m.

00:41:42.596 --> 00:41:45.846 A:middle
And then another hour
passes and we get

00:41:45.846 --> 00:41:48.176 A:middle
to what would normally
be 2:00 a.m.

00:41:48.716 --> 00:41:54.946 A:middle
But 2:00 a.m. hour is skipped
and it's totally missing

00:41:55.196 --> 00:41:58.226 A:middle
and so 3:00 a.m. is
actually the next time.

00:41:58.226 --> 00:42:02.146 A:middle
So, one hour after 1:00
a.m. is actually 3:00 a.m.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:41:58.226 --> 00:42:02.146 A:middle
So, one hour after 1:00
a.m. is actually 3:00 a.m.

00:42:02.256 --> 00:42:05.126 A:middle
in the United States on
the date of the transition.

00:42:06.086 --> 00:42:09.536 A:middle
And then time of course
continues as normal in 4:00 a.m.

00:42:09.536 --> 00:42:11.766 A:middle
and 5:00 a.m. come and go.

00:42:13.416 --> 00:42:15.706 A:middle
Now, if I'm looking for
2:30 in the morning,

00:42:16.746 --> 00:42:20.566 A:middle
the best result here
2:30 is actually missing.

00:42:20.566 --> 00:42:22.776 A:middle
There is no 2:30
a.m. on that day.

00:42:23.166 --> 00:42:28.486 A:middle
Well, if I pass in the
NSCalendarMatchNextTime option,

00:42:29.086 --> 00:42:32.286 A:middle
what that means is, you said,

00:42:32.286 --> 00:42:34.736 A:middle
you want the next
time which exists.

00:42:35.186 --> 00:42:37.546 A:middle
And so in this case, the
next time which exist

00:42:37.546 --> 00:42:44.416 A:middle
after the most desirable
time is 3:00 a.m. If instead,

00:42:44.416 --> 00:42:47.236 A:middle
you pass in the
NSCalendarMatchNext

00:42:48.586 --> 00:42:51.666 A:middle
TimePreservingSmallerUnits,

00:42:52.486 --> 00:42:55.916 A:middle
what we'll get is 3:00
a.m. out of the algorithm.

00:42:56.406 --> 00:43:00.166 A:middle
So, what this has
said is you want us

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:42:56.406 --> 00:43:00.166 A:middle
So, what this has
said is you want us

00:43:00.166 --> 00:43:05.326 A:middle
to give you the best
answer within the next hour,

00:43:05.916 --> 00:43:09.926 A:middle
in this particular case,
where we give you the minutes

00:43:09.926 --> 00:43:13.266 A:middle
and the seconds that you
requested even though we can't

00:43:13.266 --> 00:43:15.186 A:middle
give you the hour
that you requested.

00:43:15.816 --> 00:43:18.076 A:middle
And then of course
there is the reverse

00:43:18.076 --> 00:43:20.796 A:middle
which is NSCalendarMatchPrevious

00:43:21.106 --> 00:43:22.646 A:middle
TimePreservingSmallerUnits.

00:43:22.646 --> 00:43:27.936 A:middle
And here you get 1:30 instead of
the most desirable answer 2:30

00:43:27.936 --> 00:43:29.996 A:middle
which of course as
I say doesn't exist.

00:43:30.526 --> 00:43:33.396 A:middle
Now, if you had passed

00:43:33.396 --> 00:43:36.206 A:middle
in instead the
NSCalendarMatchStricly option,

00:43:36.616 --> 00:43:40.686 A:middle
what happens instead is there
is no 2:30 but you've asked

00:43:40.686 --> 00:43:43.786 A:middle
for a strict match and so
the result you get is going

00:43:43.786 --> 00:43:44.976 A:middle
to be in the next day.

00:43:49.766 --> 00:43:53.606 A:middle
Well, I have a friend who
works at the local airport

00:43:53.906 --> 00:43:56.336 A:middle
and he needs to be
at work at 3:30

00:43:56.336 --> 00:44:00.826 A:middle
in the morning before the first
international flights takeoff

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:43:56.336 --> 00:44:00.826 A:middle
in the morning before the first
international flights takeoff

00:44:00.826 --> 00:44:02.616 A:middle
and before the first
passengers arrive

00:44:02.656 --> 00:44:04.016 A:middle
for those international flights.

00:44:04.476 --> 00:44:07.956 A:middle
And he uses a fairly simple
alarm clock application

00:44:08.886 --> 00:44:12.366 A:middle
where he just specifies what
time he wants his alarm.

00:44:12.946 --> 00:44:16.226 A:middle
So, he sets his alarm for 2:30
in the morning and so he is

00:44:16.606 --> 00:44:18.656 A:middle
of course, you know,
right in the crosshairs

00:44:18.656 --> 00:44:22.166 A:middle
for this particular issue
to occur every spring.

00:44:24.726 --> 00:44:26.896 A:middle
Well, 2:30 in the
morning doesn't exist

00:44:26.966 --> 00:44:29.916 A:middle
on that transition day
in the United States.

00:44:30.606 --> 00:44:33.176 A:middle
And so, what happens?

00:44:33.246 --> 00:44:35.956 A:middle
Well, if the alarm clock
application were to pass

00:44:35.956 --> 00:44:38.796 A:middle
in the NSCalendarMatchNextTime
option.

00:44:39.516 --> 00:44:41.576 A:middle
The alarm clock is going
to ring at 3:00 a.m.

00:44:42.246 --> 00:44:44.576 A:middle
and he'll have 30 minutes
to get to work instead

00:44:44.576 --> 00:44:46.346 A:middle
of the usual hour that he needs.

00:44:47.526 --> 00:44:49.106 A:middle
If instead, it passes

00:44:49.106 --> 00:44:52.116 A:middle
in the
NextTimePreservingSmallerUnits

00:44:52.896 --> 00:44:58.296 A:middle
option, it's going to ring the
alarm at 3:30 in the morning

00:44:58.296 --> 00:45:00.086 A:middle
and he'll have no
warning to get to work.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:44:58.296 --> 00:45:00.086 A:middle
and he'll have no
warning to get to work.

00:45:00.086 --> 00:45:04.776 A:middle
On the other hand, if it passes
in the PreviousTimePreserving

00:45:04.776 --> 00:45:09.486 A:middle
SmallerUnits option, it's going
to ring at 1:30 and he's going

00:45:09.486 --> 00:45:13.916 A:middle
to have an hour or two groups
of 30 minutes before and after

00:45:13.916 --> 00:45:15.666 A:middle
that missing gap of time

00:45:16.276 --> 00:45:19.426 A:middle
so he'll have his usual
hour to get to work.

00:45:19.426 --> 00:45:20.996 A:middle
So, that's sound
like a good option.

00:45:22.546 --> 00:45:25.876 A:middle
If instead it uses the
strictly option, he's not going

00:45:25.876 --> 00:45:28.476 A:middle
to get any alarm
that rings at all.

00:45:28.476 --> 00:45:29.896 A:middle
It's going to ring the next day

00:45:30.256 --> 00:45:33.276 A:middle
because it will continue
its search and find a 2:30

00:45:33.276 --> 00:45:36.636 A:middle
in the morning on the next day
and not ring this day at all.

00:45:38.096 --> 00:45:41.256 A:middle
So, what my friend really
wants to specify isn't 2:30

00:45:41.736 --> 00:45:43.506 A:middle
with his alarm clock
application.

00:45:44.146 --> 00:45:47.146 A:middle
He really wants to specify
one hour before 3:30

00:45:47.146 --> 00:45:49.936 A:middle
so it'd be much nicer
if the user interface

00:45:49.936 --> 00:45:54.696 A:middle
of this alarm clock had two
controls, one which was a time

00:45:54.756 --> 00:45:58.226 A:middle
and one which was a relative
time before that time

00:45:58.656 --> 00:46:00.286 A:middle
at which you want
to begin searching.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:45:58.656 --> 00:46:00.286 A:middle
at which you want
to begin searching.

00:46:00.586 --> 00:46:04.306 A:middle
Of course even nicer might be
for the alarm clock application

00:46:04.306 --> 00:46:09.136 A:middle
to warn him that his desired
time doesn't actually exist,

00:46:09.396 --> 00:46:12.226 A:middle
you know, when it's like a
day before the transition

00:46:12.886 --> 00:46:15.226 A:middle
and give him an alert
saying "Hey, you know,

00:46:15.666 --> 00:46:18.786 A:middle
there's a Daylight Savings Time
transition coming up, you know,

00:46:18.786 --> 00:46:20.176 A:middle
you got an issue here."

00:46:21.616 --> 00:46:23.386 A:middle
Maybe you'd ask him, "What
do you want me to do?"

00:46:23.386 --> 00:46:26.406 A:middle
or it just says, "I'm going to
wake you up at 1:30 instead."

00:46:26.966 --> 00:46:30.626 A:middle
Another way to look
at the question

00:46:30.626 --> 00:46:33.786 A:middle
of what is the best
option is to look

00:46:33.786 --> 00:46:36.756 A:middle
at what normally
happens around this gap.

00:46:37.196 --> 00:46:39.826 A:middle
So, in the United States,
they put the transition

00:46:39.826 --> 00:46:41.036 A:middle
in the middle of the weekend.

00:46:41.036 --> 00:46:44.086 A:middle
That is early in the morning
Sundays so it's is right

00:46:44.086 --> 00:46:45.026 A:middle
in the middle of the weekend.

00:46:45.026 --> 00:46:50.076 A:middle
And so, what happens if you
just look at, say, 6:00 a.m. is

00:46:50.076 --> 00:46:52.806 A:middle
that from Friday 6:00 a.m.
to Saturday 6:00 a.m.,

00:46:52.806 --> 00:46:55.056 A:middle
there's an ordinary
period of 24 hours,

00:46:55.406 --> 00:46:58.156 A:middle
then from Saturday 6:00
a.m. to Sunday 6:00 a.m.,

00:46:58.316 --> 00:46:59.886 A:middle
there's just 23 hours.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:47:00.056 --> 00:47:02.876 A:middle
But then again, from
Sunday 6:00 a.m.

00:47:02.926 --> 00:47:05.946 A:middle
to Monday 6:00 a.m. there's
a period of 24 hours.

00:47:06.516 --> 00:47:10.926 A:middle
So, what happens every year is
same old cliché joke is try it

00:47:10.926 --> 00:47:13.736 A:middle
out, "Oh, you're going to have
one hour less of sleep tonight."

00:47:13.736 --> 00:47:15.156 A:middle
And that happens, you know,

00:47:15.156 --> 00:47:18.696 A:middle
Saturday night all the news
reporters talk about that

00:47:18.986 --> 00:47:21.676 A:middle
to remind people about the
Daylight Saving Time change.

00:47:21.916 --> 00:47:24.016 A:middle
One hour less sleep
but that occurs

00:47:24.016 --> 00:47:25.246 A:middle
in the middle of the weekend.

00:47:25.586 --> 00:47:30.246 A:middle
That's kind of the point why
the U.S. does that transition

00:47:30.246 --> 00:47:31.216 A:middle
in the middle of the weekend.

00:47:32.236 --> 00:47:35.336 A:middle
Well, let's go back and
shift our timeline again back

00:47:35.386 --> 00:47:37.246 A:middle
to the 2:30 example.

00:47:38.516 --> 00:47:42.426 A:middle
So, if I ask for
NSCalendarMatchNextTime

00:47:42.686 --> 00:47:46.956 A:middle
to get 3:00 a.m., what will
happen is a 24 hour period

00:47:46.956 --> 00:47:49.966 A:middle
occurs from Friday
to Saturday then a 23

00:47:49.966 --> 00:47:54.216 A:middle
and a half hour period occurs
between alarm clock firings

00:47:54.636 --> 00:47:57.326 A:middle
on Sunday morning
and Monday morning.

00:47:57.326 --> 00:47:58.996 A:middle
So, you've kind of split
the different there.

00:47:59.136 --> 00:48:04.426 A:middle
On the other hand, if
you pass in MatchNextTime

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:47:59.136 --> 00:48:04.426 A:middle
On the other hand, if
you pass in MatchNextTime

00:48:04.796 --> 00:48:08.656 A:middle
PreservingSmallerUnits,
you get a 24-hour period

00:48:08.656 --> 00:48:11.836 A:middle
between alarm clock
firings on Saturday morning

00:48:11.966 --> 00:48:16.296 A:middle
and Sunday morning and then
your short night in a sense

00:48:16.556 --> 00:48:19.456 A:middle
or a short day is
between Sunday and Monday.

00:48:20.076 --> 00:48:22.226 A:middle
And so, it's really Monday
morning where you end

00:48:22.226 --> 00:48:23.846 A:middle
up losing that hour of sleep.

00:48:25.896 --> 00:48:29.476 A:middle
And finally, if you pass
in the MatchPreviousTime

00:48:30.236 --> 00:48:32.736 A:middle
PreservingSmallerUnits,
you get the same kind

00:48:32.736 --> 00:48:35.876 A:middle
of pattern we saw originally
where there is a 24-hour period,

00:48:36.196 --> 00:48:38.976 A:middle
a 23-hour period and
a 24-hour period.

00:48:43.186 --> 00:48:45.556 A:middle
If you need to enumerate
matches,

00:48:45.556 --> 00:48:51.396 A:middle
that is not just find one mixed
instance of a match but you want

00:48:51.396 --> 00:48:55.876 A:middle
to find all times that
match certain criteria

00:48:56.236 --> 00:49:00.446 A:middle
and enumerate them all and
do some work for each match,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:48:56.236 --> 00:49:00.446 A:middle
and enumerate them all and
do some work for each match,

00:49:01.076 --> 00:49:02.436 A:middle
then you should use this method.

00:49:03.036 --> 00:49:05.446 A:middle
The enumerate dates starting

00:49:05.446 --> 00:49:08.526 A:middle
after date method takes the
same kind of parameters,

00:49:08.526 --> 00:49:11.466 A:middle
the first parameter, the date
at which to begin searching.

00:49:11.876 --> 00:49:16.066 A:middle
It takes your date components
that you want to have matched

00:49:16.356 --> 00:49:18.956 A:middle
and some options, the
options I've explained

00:49:20.096 --> 00:49:22.136 A:middle
and you pass in a block.

00:49:22.846 --> 00:49:24.386 A:middle
The block takes three
parameters.

00:49:24.386 --> 00:49:27.566 A:middle
The first two parameters
of the block are the date

00:49:27.866 --> 00:49:29.226 A:middle
that the algorithm found

00:49:30.326 --> 00:49:33.806 A:middle
and a Boolean telling you
whether it found an exact match

00:49:33.916 --> 00:49:35.006 A:middle
or not.

00:49:35.006 --> 00:49:38.946 A:middle
If the algorithm had to fudge
the answer based, you know,

00:49:38.946 --> 00:49:42.866 A:middle
give you a 1:30 or 3:30
instead of the 2:30 you asked

00:49:42.866 --> 00:49:44.436 A:middle
for in our previous example.

00:49:45.246 --> 00:49:46.686 A:middle
This algorithm will tell you

00:49:47.116 --> 00:49:49.396 A:middle
with that Boolean whether
it had to that or not.

00:49:49.986 --> 00:49:55.166 A:middle
Then there's the third parameter
which is the mechanism you use

00:49:55.166 --> 00:49:58.406 A:middle
to stop the algorithm
when you want to stop it.

00:49:58.806 --> 00:50:01.756 A:middle
So, we've used this in
other enumerate methods,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:49:58.806 --> 00:50:01.756 A:middle
So, we've used this in
other enumerate methods,

00:50:01.756 --> 00:50:02.976 A:middle
it's the same kind of pattern.

00:50:03.666 --> 00:50:06.236 A:middle
We pass in a pointer
to a Boolean

00:50:06.736 --> 00:50:09.436 A:middle
and when the condition
arises where you want

00:50:09.436 --> 00:50:15.196 A:middle
to stop the enumeration, you
simply set the value pointed to,

00:50:15.896 --> 00:50:18.616 A:middle
you know, star stop
in this case to "Yes".

00:50:19.116 --> 00:50:22.106 A:middle
You don't need to set the
Boolean to "No" every time

00:50:22.106 --> 00:50:24.166 A:middle
to keep enumerating, it
will keep doing that.

00:50:24.306 --> 00:50:27.736 A:middle
You don't need to
set it to know ever.

00:50:28.056 --> 00:50:30.696 A:middle
You just need to set it to
"Yes" once when you want

00:50:30.696 --> 00:50:31.996 A:middle
to stop the enumeration.

00:50:32.526 --> 00:50:39.246 A:middle
So, there were some
operations that are very common

00:50:39.246 --> 00:50:41.236 A:middle
and we found lots of
people want to do a lot.

00:50:41.236 --> 00:50:47.276 A:middle
Let me talk a little bit here,
give me few minutes of talk

00:50:47.276 --> 00:50:51.766 A:middle
about testing these algorithms
and testing the calculations

00:50:51.766 --> 00:50:53.966 A:middle
that you're doing
within your application.

00:50:54.506 --> 00:50:56.216 A:middle
Well, the first thing
you need to do is

00:50:56.216 --> 00:50:58.856 A:middle
of course consider
the interesting cases.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:51:00.066 --> 00:51:02.016 A:middle
Well, what are the
interesting cases?

00:51:02.016 --> 00:51:06.026 A:middle
Well, an application today
might be used worldwide

00:51:06.026 --> 00:51:08.626 A:middle
and so you need to
consider different locales

00:51:08.626 --> 00:51:13.066 A:middle
and different calendars that
the local users, you know,

00:51:13.346 --> 00:51:15.266 A:middle
in a given area might be using.

00:51:15.956 --> 00:51:18.986 A:middle
So, you need to test different
locales and calendars.

00:51:19.086 --> 00:51:23.366 A:middle
Of course, these different users
around the world are existing

00:51:23.366 --> 00:51:26.246 A:middle
and living in different
time zones so it's good

00:51:26.246 --> 00:51:28.646 A:middle
to get some testing within
different time zones.

00:51:29.106 --> 00:51:31.696 A:middle
But you also need to
consider the cycle boundaries,

00:51:31.696 --> 00:51:33.286 A:middle
where are the interesting cases.

00:51:33.746 --> 00:51:36.306 A:middle
Well, these various cycles
of time, for example,

00:51:36.306 --> 00:51:39.176 A:middle
hours go from, say, 0 to 23

00:51:39.456 --> 00:51:43.106 A:middle
and then the cycle repeats the
next day, 0 to 23 and so on.

00:51:43.546 --> 00:51:47.476 A:middle
So, an example of a cycle
boundary is the end of a day

00:51:47.536 --> 00:51:50.576 A:middle
or the beginning of a day
is the same thing, midnight.

00:51:51.896 --> 00:51:54.876 A:middle
But you also have interesting
things that can happen

00:51:54.876 --> 00:51:57.506 A:middle
at the end of months or at
the end of years or beginning

00:51:57.506 --> 00:51:58.786 A:middle
of years, it's the same thing.

00:51:59.336 --> 00:52:04.356 A:middle
In some cases, some calendars,
the Era is really important

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:51:59.336 --> 00:52:04.356 A:middle
In some cases, some calendars,
the Era is really important

00:52:05.336 --> 00:52:08.646 A:middle
to also test for
and keep in mind.

00:52:10.156 --> 00:52:11.776 A:middle
What kind of things
do you look for?

00:52:11.776 --> 00:52:13.766 A:middle
Well, you look for
incorrect results.

00:52:14.656 --> 00:52:17.966 A:middle
It's very obvious but very
dull answer, right and obvious.

00:52:18.256 --> 00:52:19.896 A:middle
Well, you look for
incorrect results.

00:52:20.016 --> 00:52:24.256 A:middle
Well, the real question here is,
how do you know that the answers

00:52:24.256 --> 00:52:26.906 A:middle
that you're seeing, that the
answers you're getting are the

00:52:26.906 --> 00:52:27.986 A:middle
correct answers?

00:52:29.466 --> 00:52:30.846 A:middle
Well, what can you do?

00:52:30.846 --> 00:52:33.836 A:middle
You have to find some sort
of authoritative information.

00:52:34.176 --> 00:52:37.586 A:middle
Like, how do I know that
it's, you know, a certain year

00:52:37.586 --> 00:52:41.376 A:middle
within the Hebrew Calendar, I'm
being told 5,700 and something.

00:52:41.486 --> 00:52:43.166 A:middle
Well, how do I know
that's correct?

00:52:43.656 --> 00:52:46.416 A:middle
Well, you have to find some sort
of authoritative information.

00:52:46.416 --> 00:52:49.716 A:middle
Well, there's these old
fashion things called Almanacs

00:52:49.716 --> 00:52:53.106 A:middle
which are going to help in
books and of course nowadays,

00:52:53.106 --> 00:52:54.936 A:middle
I tend to use the internet a lot

00:52:55.496 --> 00:52:57.556 A:middle
and so I do a search
on the internet.

00:52:57.776 --> 00:53:00.016 A:middle
What is the current
Islamic Calendar year?

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:52:57.776 --> 00:53:00.016 A:middle
What is the current
Islamic Calendar year?

00:53:00.256 --> 00:53:00.786 A:middle
For example.

00:53:01.556 --> 00:53:04.396 A:middle
And I don't just look at
one website of course.

00:53:04.496 --> 00:53:07.716 A:middle
I look at many websites
and compare their answer.

00:53:08.226 --> 00:53:10.456 A:middle
And you can also ask people.

00:53:10.556 --> 00:53:14.286 A:middle
So, if you have people
that you know or can ask

00:53:14.286 --> 00:53:19.336 A:middle
about the answer, you know, you
can verify it with real people

00:53:19.516 --> 00:53:22.326 A:middle
and I'll get to that--
back to that in a second.

00:53:23.126 --> 00:53:24.556 A:middle
So, how do you test?

00:53:25.706 --> 00:53:28.986 A:middle
Well, to literally
test of course,

00:53:28.986 --> 00:53:31.266 A:middle
you have to turn off the
time syncing on the device,

00:53:31.266 --> 00:53:35.316 A:middle
on the computer or on iPhone
or iPad, what have you.

00:53:36.426 --> 00:53:39.166 A:middle
Then you, of course, you
can set the clock manually.

00:53:39.926 --> 00:53:42.006 A:middle
You can set the time
zone to different values.

00:53:42.006 --> 00:53:44.086 A:middle
You can set the calendar
in locale

00:53:44.416 --> 00:53:47.836 A:middle
to different values
manually and, you know,

00:53:48.076 --> 00:53:49.676 A:middle
try out your application.

00:53:51.186 --> 00:53:54.596 A:middle
But, perhaps a more
valuable thing to do is

00:53:54.596 --> 00:53:57.836 A:middle
to develop some variety
within your beta tester pool.

00:53:58.336 --> 00:54:02.636 A:middle
So, if, you know, assuming you
have some people that you ask

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:53:58.336 --> 00:54:02.636 A:middle
So, if, you know, assuming you
have some people that you ask

00:54:02.716 --> 00:54:08.406 A:middle
to beta test your application,
you can try to collect a group

00:54:08.466 --> 00:54:12.186 A:middle
of people which live in
different time zones,

00:54:12.186 --> 00:54:15.026 A:middle
which live in different
locales of the world

00:54:15.366 --> 00:54:16.326 A:middle
and they will naturally

00:54:16.326 --> 00:54:19.826 A:middle
of course know the right answer
'cause at worse, they can look

00:54:19.826 --> 00:54:23.926 A:middle
at a newspaper or ask their
friend what the day is

00:54:23.926 --> 00:54:24.626 A:middle
if they don't know.

00:54:25.046 --> 00:54:28.346 A:middle
But they'll know what the right
answers are and they'll be able

00:54:28.346 --> 00:54:32.996 A:middle
to tell you what, you know,
what you're doing wrong

00:54:32.996 --> 00:54:36.316 A:middle
when something happens that's
wrong within their application.

00:54:36.776 --> 00:54:39.416 A:middle
But another thing you can
do is direct their testing.

00:54:39.416 --> 00:54:42.186 A:middle
Tell them, you know,
what-- if you say, "Well,

00:54:42.186 --> 00:54:45.836 A:middle
this guy in my beta
tester pool lives in China.

00:54:45.836 --> 00:54:46.736 A:middle
I know he lives in China.

00:54:47.316 --> 00:54:51.156 A:middle
You can ask him specifically,
"Can you test, you know,

00:54:51.226 --> 00:54:52.306 A:middle
this or that bit

00:54:52.306 --> 00:54:54.516 A:middle
of functionality in
this or that way?"

00:54:54.516 --> 00:54:56.146 A:middle
So, you can direct
their testing rather

00:54:56.146 --> 00:54:58.536 A:middle
than just giving them
the app and say, "Oh,

00:54:58.536 --> 00:55:01.176 A:middle
here's a new version,
go try it out."

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:54:58.536 --> 00:55:01.176 A:middle
here's a new version,
go try it out."

00:55:01.816 --> 00:55:06.196 A:middle
So, I've talked about various
kinds of common operations

00:55:06.196 --> 00:55:09.856 A:middle
and we've added some API for
and there are many new methods

00:55:09.856 --> 00:55:11.916 A:middle
that we added that I
didn't talk about today.

00:55:11.916 --> 00:55:15.786 A:middle
You have to go and look at
the NSCalendar documentation,

00:55:15.786 --> 00:55:19.116 A:middle
the NSCalendar.h
Header to see those.

00:55:19.866 --> 00:55:23.316 A:middle
If you had some feedback
on this talk, you can talk

00:55:23.316 --> 00:55:25.816 A:middle
to our Evangelist Paul Marcos.

00:55:26.636 --> 00:55:29.546 A:middle
The Date & Time Programming
Guide is very good.

00:55:30.006 --> 00:55:31.666 A:middle
I recommend reading that.

00:55:32.106 --> 00:55:34.206 A:middle
And of course, there's
the documentation

00:55:34.206 --> 00:55:37.316 A:middle
for the specific classes that
I talked about like NSCalendar.

00:55:37.546 --> 00:55:40.236 A:middle
And of course, the
Developer Forums, our resource

00:55:40.236 --> 00:55:42.356 A:middle
for asking questions
about these things.

00:55:42.986 --> 00:55:44.546 A:middle
And with that, I thank you.

00:55:45.516 --> 00:55:50.500 A:middle
[ Applause ]