view release on metacpan or  search on metacpan

lib/Date/Manip/TZ.pod  view on Meta::CPAN

used, so, unless dates from around the world are being parsed, only a
very small number of these modules will actually be loaded. In many
applications, only a single TZ module will be loaded. If parsing
dates which have timezone information stored as offsets, one or two
Offset modules will also be loaded.

=item B<The disk space seems excessive>

Currently, the disk usage of the perl files is around 9 MB. Total disk
usage for /usr/share/zoneinfo on my computer is around 4 MB. There are
a couple of differences.

The primary difference is that the zoneinfo files are stored in a binary
(and hence, more compressed) version, where the perl modules have all
the data in pure text.

Since these are all automatically generated and used, it may be
beneficial to store the data in some packed binary format instead of
the fully expanded text form that is currently in use. This would
decrease the disk space usage, and might improve performance. However,
the performance improvement would happen only once per timezone, and
would make for more complicated code, so I'm not very interested in
pursuing this.

Another aspect of the current modules is that they all include pod
documentation. Although not necessary, this allows users to easily
see what modules handle which time zones, and that's nice. It also
allows me to use pod_coverage tests for the module which is a nice
check to make sure that the documentation is accurate.

All told, I don't consider the disk usage excessive at all.

=back

=head1 KNOWN PROBLEMS OR ISSUES

=over 4

=item B<Unable to determine Time Zone>

When using Date::Manip, when the module is initialized, it must be
able to determine the local time zone. If it fails to do so, an
error will occur:

   Unable to determine Time Zone

and the script will exit.

In the past, this was the most common problem with using Date::Manip .
With the release of 6.00, this problem should be significantly less
common. If you do get this error, please refer to the section above
DETERMINING THE SYSTEM TIME ZONE for information about determining the
local time zone. I am also interested in hearing about this so that I
can update the default list of methods to be able to determine the
local time zone better.

=item B<Asia/Jerusalem time zone>

The Asia/Jerusalem time zone has a non-standard way of specifying
the start and end of Daylight Saving Time based on the Hebrew
calendar.

As a result, there is no way to specify a simple rule to define
time zone changes for all years in the future. As such, this module
supports all time zone changes currently specified in the zoneinfo
database (which currently goes to the year 2037) but does not attempt
to correctly handle zone changes beyond that date. As a result,
Date::Manip should not be used to parse dates in the Jerusalem
time zone that are far enough in the future that information is not
included in the current version of the zoneinfo database.

=item B<LMT and zzz abbreviations>

Both the LMT and zzz abbreviations are used in the zoneinfo databases.
LMT is use for most time zones for the times before the Gregorian
calendar was adopted, and zzz is used for a few where the time zone was
created and no description of dates prior to that are supported. Both
LMT and zzz are basically ignored in parsing dates (because there is
no reasonable way to determine which zone they are referring to), and
will be treated as the local time zone regardless.

=back

=head1 KNOWN BUGS

None known.

=head1 BUGS AND QUESTIONS

Please refer to the Date::Manip::Problems documentation for
information on submitting bug reports or questions to the author.

=head1 SEE ALSO

Date::Manip        - main module documentation

=head1 LICENSE

This script is free software; you can redistribute it and/or
modify it under the same terms as Perl itself.

=head1 AUTHOR

Sullivan Beck (sbeck@cpan.org)

=cut