File perl-Time-Tiny.spec of Package perl-Time-Tiny

#
# spec file for package perl-Time-Tiny
#
# Copyright (c) 2012 SUSE LINUX Products GmbH, Nuernberg, Germany.
#
# All modifications and additions to the file contributed by third parties
# remain the property of their copyright owners, unless otherwise agreed
# upon. The license for this file, and modifications and additions to the
# file, is the same license as for the pristine package itself (unless the
# license for the pristine package is not an Open Source License, in which
# case the license is the MIT License). An "Open Source License" is a
# license that conforms to the Open Source Definition (Version 1.9)
# published by the Open Source Initiative.

# Please submit bugfixes or comments via http://bugs.opensuse.org/
#


Name:           perl-Time-Tiny
Version:        1.05
Release:        0
%define cpan_name Time-Tiny
Summary:        A time object, with as little code as possible
License:        GPL-1.0+ or Artistic-1.0
Group:          Development/Libraries/Perl
Url:            http://search.cpan.org/dist/Time-Tiny/
Source:         http://www.cpan.org/authors/id/A/AD/ADAMK/Time-Tiny-%{version}.tar.gz
BuildRequires:  perl
BuildRequires:  perl-macros
BuildRoot:      %{_tmppath}/%{name}-%{version}-build
BuildArch:      noarch
%{perl_requires}

%description
*Time::Tiny* is a member of the the DateTime::Tiny manpage suite of time
modules.

It implements an extremely lightweight object that represents a time,
without any time data.

The Tiny Mandate
    Many CPAN modules which provide the best implementation of a concept
    can be very large. For some reason, this generally seems to be about 3
    megabyte of ram usage to load the module.

    For a lot of the situations in which these large and comprehensive
    implementations exist, some people will only need a small fraction of
    the functionality, or only need this functionality in an ancillary
    role.

    The aim of the Tiny modules is to implement an alternative to the large
    module that implements a subset of the functionality, using as little
    code as possible.

    Typically, this means a module that implements between 50% and 80% of
    the features of the larger module, but using only 100 kilobytes of
    code, which is about 1/30th of the larger module.

The Concept of Tiny Date and Time
    Due to the inherent complexity, Date and Time is intrinsically very
    difficult to implement properly.

    The arguably *only* module to implement it completely correct is the
    DateTime manpage. However, to implement it properly the DateTime
    manpage is quite slow and requires 3-4 megabytes of memory to load.

    The challenge in implementing a Tiny equivalent to DateTime is to do so
    without making the functionality critically flawed, and to carefully
    select the subset of functionality to implement.

    If you look at where the main complexity and cost exists, you will find
    that it is relatively cheap to represent a date or time as an object,
    but much much more expensive to modify or convert the object.

    As a result, *Time::Tiny* provides the functionality required to
    represent a date as an object, to stringify the date and to parse it
    back in, but does *not* allow you to modify the dates.

    The purpose of this is to allow for date object representations in
    situations like log parsing and fast real-time work.

    The problem with this is that having no ability to modify date limits
    the usefulness greatly.

    To make up for this, *if* you have the DateTime manpage installed, any
    *Time::Tiny* module can be inflated into the equivalent the DateTime
    manpage as needing, loading the DateTime manpage on the fly if
    necesary.

    For the purposes of date/time logic, all *Time::Tiny* objects exist in
    the "C" locale, and the "floating" time zone (although obviously in a
    pure date context, the time zone largely doesn't matter).

    When converting up to full the DateTime manpage objects, these local
    and time zone settings will be applied (although an ability is provided
    to override this).

    In addition, the implementation is strictly correct and is intended to
    be very easily to sub-class for specific purposes of your own.

%prep
%setup -q -n %{cpan_name}-%{version}

%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
%{__make} %{?_smp_mflags}

%check
%{__make} test

%install
%perl_make_install
%perl_process_packlist
%perl_gen_filelist

%clean
%{__rm} -rf %{buildroot}

%files -f %{name}.files
%defattr(644,root,root,755)
%doc Changes LICENSE README

%changelog