- Choosing a Database Extension 1:34
- Choosing a database extension 3 questions
- Working with DateTime 4:21
- Review: Working with DateTime 3 questions
- DateTime Comparisons 2:33
- DateTime Comparisons 3 questions
- Understanding Time Zones 3:56
- Understanding Timezones 3 questions
- Understanding UTF-8 4:14
- Understanding UTF-8 3 questions
Preview
Video Player
00:00
00:00
Understanding Time Zones
3:56There are a lot of things that can catch you out when working with time zones, but PHP has you covered with built in Time Zone support for the DateTime class.
Time zones can be a very difficult aspect
of web development to understand.
0:00
There are different time zones all over
the world and
0:03
most of these time zones are not as
logical as you would hope.
0:06
Every country has a different time and
0:09
you want to make sure that you're showing
the user in that country the right time.
0:11
There are some tricky caveats.
0:14
Not all time zones are exactly one hour
plus or minus UTC.
0:17
So storing a plus or minus integer doesn't
work.
0:20
Not all time zones have daylight savings
time.
0:22
Political events can cause time zones to
change their off set.
0:25
Many developers approach this by always
storing dates in their database’s UTC.
0:29
Any date going in is converted to UTC on
input, and back from UTC on display.
0:33
To calculate times and offsets, many
developers store plus 1 or
0:39
minus 4 as an offset and put that in their
database as an integer.
0:42
This means that if the country's offset is
minus four and
0:46
a half hours, then the numeric
representation is minus 4.5.
0:49
This is a decimal, and if you try to put
decimal numbers into an integer field,
0:52
it'll be truncated by MySQL and only the
value 4 will be saved.
0:57
Even storing a decimal number would not
help if DST or
1:02
time zone change came into effect.
1:05
The time being displayed to the user would
still be wrong by as much as an hour.
1:07
The more robust way to work with dates and
times in PHP,
1:12
is to store the actual time zone in the
database and not just the offset.
1:15
PHP uses IANA time zones which are an
internationally recognized body in
1:19
charge of handling mapping of these times
zones and keeping them up to date.
1:24
Let's take a look at some code.
1:28
First this might look like a lot of code,
but when broken down it's pretty simple.
1:30
On line 3 we have a new date/time object
just as before, using a supported format.
1:33
We've also specified the second argument
of the date time class which is
1:37
an instance of date time zone.
1:41
This accepts a string with a name of a
time zone, and
1:43
UTC is the one we want here.
1:45
Next we clone that date so we can keep a
copy of the original.
1:47
We do this because date time is a mutable
class.
1:50
That means the object will change state
when we run methods like set time zone.
1:53
So that we can keep a copy we have to
fully clone the object.
1:57
Then work with a brand new version.
2:00
On line 7,
2:02
we now use the set time zone method on our
new copy of the UTC date/time instance.
2:03
And the string American New York is a
supported IANA time zone name.
2:08
This will update the local date/time
object to have a new time zone and
2:12
therefore a new time.
2:16
Finally, at the bottom of the script,
we’re outputting two
2:17
paragraphs with the date and time for UTC
and another for the time in New York.
2:21
Let’s have a look at that in the preview.
2:26
Great, it looks like that worked.
2:30
1314 in UTC is now showing 0914 in New
York, which is exactly right.
2:32
All dates should be stored as UTC in the
database.
2:37
The date should always be displayed to the
user in their own time zone.
2:39
This sounds complicated.
2:42
But it simply means you need to convert
from UTC to the local time zone
2:43
for output.
2:46
Then convert from the local time zone to
UTC on input.
2:47
Let's get back to our workspace and see
what that code might look like.
2:50
This is basically the same piece of code
we had before.
2:53
We just swapped things around.
2:55
Now it's worth noting that you'll probably
take your input from a superglobal such
2:56
as a post variable.
3:00
But, for the sake of simplicity, we're
going to use just a raw variable here.
3:01
Now, the rest of this is pretty much the
same.
3:05
We're creating a local date/time from the
American New York timezone.
3:08
We're cloning that to make a UTC date time
object, and
3:13
then we're setting the time zone of that
to UTC.
3:15
So now if we run this, it should look
exactly the same as before.
3:19
Perfect.
We've still got 13 o'clock and
3:24
we have nine o'clock right there.
3:26
By storing the time zone name itself the
various offsets for
3:29
day light savings time or [UNKNOWN]
changes are handled for you.
3:32
All you then need to do is store all dates
in UTC and update the one output.
3:35
So, just remember, all dates are stored in
a database as UTC.
3:39
All users should have a time zone attached
to their own account.
3:43
That time zone should be a valid IANA
name, and whenever you output dates,
3:45
you need to set the time zone of that date
to match the user's time zone.
3:51
Let's try a few questions on UTC and time
zones.
3:54