Description: spelling fixes
Origin: vendor
Author: gregor herrmann <gregoa@debian.org>
Last-Update: 2017-06-30
Forwarded: https://rt.cpan.org/Ticket/Display.html?id=122278
Bug: https://rt.cpan.org/Ticket/Display.html?id=122278

--- a/lib/Schedule/Cron.pm
+++ b/lib/Schedule/Cron.pm
@@ -543,7 +543,7 @@
 In addition, ranges or lists of names are allowed. 
 
 An optional sixth column can be used to specify the seconds within the
-minute. If not present, it is implicitely set to "0".
+minute. If not present, it is implicitly set to "0".
 
 B<Command specification>
 
@@ -683,7 +683,7 @@
 Note that these entries are returned by value and were opbtained from the
 internal list by a deep copy. I.e. you are free to modify it, but this won't
 influence the original entries. Instead use C<update_entry> if you need to
-modify an exisiting crontab entry.
+modify an existing crontab entry.
 
 =cut
 
@@ -761,7 +761,7 @@
 
 =item $cron->update_entry($idx,$entry)
 
-Updates the entry with index C<$idx>. C<$entry> is a hash ref as descibed in
+Updates the entry with index C<$idx>. C<$entry> is a hash ref as described in
 C<list_entries()> and must contain at least a value C<$entry-E<gt>{time}>. If no
 C<$entry-E<gt>{dispatcher}> is given, then the default dispatcher is used.  This
 method returns the old entry on success, C<undef> otherwise.
@@ -1811,11 +1811,11 @@
 calculates epoch times for dates given like C<02:50:00 2009/10/25>. Should it
 return the seconds since 1970 for this time happening 'first', or for this time
 in the extra hour ? As it turns out, L<Time::ParseDate> returns the epoch time
-of the first occurence for C<PST8PDT> and for C<MET> it returns the second
-occurence. Unfortunately, there is no way to specify I<which> entry
+of the first occurrence for C<PST8PDT> and for C<MET> it returns the second
+occurrence. Unfortunately, there is no way to specify I<which> entry
 L<Time::ParseDate> should pick (until now). Of course, after all, this is
 obviously not L<Time::ParseDate>'s fault, since a simple date specification
-within the DST backswitch period B<is> ambigious. However, it would be nice if
+within the DST backswitch period B<is> ambiguous. However, it would be nice if
 the parsing behaviour of L<Time::ParseDate> would be consistent across time
 zones (a ticket has be raised for fixing this). Then L<Schedule::Cron>'s
 behaviour within a DST backward switch would be consistent as well.