Use "time zone" instead of "timezone" everywhere (#7917)

There is a mix of "timezone" and "time zone" in the codebase. For what I read, "time zone" is usually more correct.

In addition, there are some variables and types named `time_zone`, so I think the best option is to go with "time zone".

Signed-off-by: José Valim <jose.valim@plataformatec.com.br>

Author: fertapric

lib/elixir/lib/calendar/datetime.ex

@@ -17,20 +17,20 @@ defmodule DateTime do
   Such functions expect `t:Calendar.datetime/0` in their typespecs
   (instead of `t:t/0`).
 
-  Developers should avoid creating the DateTime struct directly
+  Developers should avoid creating the `DateTime` struct directly
   and instead rely on the functions provided by this module as
   well as the ones in 3rd party calendar libraries.
 
   ## Where are my functions?
 
   You will notice this module only contains conversion
   functions as well as functions that work on UTC. This
-  is because a proper DateTime implementation requires a
-  TimeZone database which currently is not provided as part
+  is because a proper `DateTime` implementation requires a
+  time zone database which currently is not provided as part
   of Elixir.
 
   Such may be addressed in upcoming versions, meanwhile,
-  use 3rd party packages to provide DateTime building and
+  use 3rd party packages to provide `DateTime` building and
   similar functionality with time zone backing.
   """
 

lib/elixir/lib/calendar/naive_datetime.ex

@@ -412,7 +412,7 @@ defmodule NaiveDateTime do
   Parses the extended "Date and time of day" format described by
   [ISO 8601:2004](https://en.wikipedia.org/wiki/ISO_8601).
 
-  Timezone offset may be included in the string but they will be
+  Time zone offset may be included in the string but they will be
   simply discarded as such information is not included in naive date
   times.
 

lib/elixir/lib/calendar/time.ex

@@ -177,7 +177,7 @@ defmodule Time do
   Parses the extended "Local time" format described by
   [ISO 8601:2004](https://en.wikipedia.org/wiki/ISO_8601).
 
-  Timezone offset may be included in the string but they will be
+  Time zone offset may be included in the string but they will be
   simply discarded as such information is not included in times.
 
   As specified in the standard, the separator "T" may be omitted if

lib/elixir/lib/kernel.ex

@@ -70,10 +70,10 @@ defmodule Kernel do
   listed above. Some of them are:
 
     * `Date` - `year-month-day` structs in a given calendar
-    * `DateTime` - date and time with timezone in a given calendar
+    * `DateTime` - date and time with time zone in a given calendar
     * `Exception` - data raised from errors and unexpected scenarios
     * `MapSet` - unordered collections of unique elements
-    * `NaiveDateTime` - date and time without timezone in a given calendar
+    * `NaiveDateTime` - date and time without time zone in a given calendar
     * `Keyword` - lists of two-element tuples, often representing optional values
     * `Range` - inclusive ranges between two integers
     * `Regex` - regular expressions

lib/iex/lib/iex/info.ex

@@ -338,7 +338,7 @@ defimpl IEx.Info, for: [Date, Time, NaiveDateTime] do
     case @for do
       Date -> {"D", "date"}
       Time -> {"T", "time"}
-      NaiveDateTime -> {"N", ~S{"naive" datetime (that is, a datetime without a timezone)}}
+      NaiveDateTime -> {"N", ~S{"naive" datetime (that is, a datetime without a time zone)}}
     end
 
   def info(value) do

lib/iex/test/iex/info_test.exs

@@ -194,7 +194,7 @@ defmodule IEx.InfoTest do
       assert get_key(info, "Reference modules") == "NaiveDateTime, Calendar, Map"
 
       assert get_key(info, "Description") =~
-               ~S{a "naive" datetime (that is, a datetime without a timezone)}
+               ~S{a "naive" datetime (that is, a datetime without a time zone)}
 
       assert get_key(info, "Description") =~ "`~N`"
     end