libdate-calc-perl (6.3-1) unstable; urgency=low

  Since version 6.2, Date::Calc only contains a pure Perl
  implementation.  The XS-accelerated implementation was separated into
  its own package, libdate-calc-xs-perl, and will automatically be used
  when installed.

 -- Florian Schlichting <fschlich@zedat.fu-berlin.de>  Mon, 12 Sep 2011 21:44:37 +0200

libdate-calc-perl (6.0-1) unstable; urgency=low

  In version 6.0 of Date::Calc the interface to DateCalc.c has changed. Thus
  check for details `/usr/share/doc/lidate-calc-perl/README.txt.gz'.

  Backward compatibility:
  -----------------------

  Module "Date::Calc" should be 100% backward compatible, meaning
  that no changes to existing code using reasonably recent versions
  of "Date::Calc" should be necessary (consult the changes history
  in file "CHANGES.txt" for possible incompatible changes between
  versions).

  Note that when you pass an invalid language number to any of the
  affected functions, you will get the previous behaviour, in which
  a global variable (set by the function "Language()") determines
  the language to be used.

  Note again that this new language parameter in the affected functions
  is optional; omitting it gives you the previous behaviour with the
  global variable as well (this is where the compatibility with existing
  code stems from).

  When using the C library "DateCalc.c", where omitting a parameter
  is not an option, passing a zero for the language is therefore the
  recommended way to guarantee backward compatibility and to keep
  changes to existing code to a minimum.

  Modules "Date::Calc::Object" and "Date::Calendar::Year" should be
  backward compatible as well (modules "Date::Calendar" and
  "Date::Calendar::Profiles" have not been changed).

  However, because the global variable (the one set by the function
  "Language()") is not set temporarily anymore by language-dependent
  methods and overridden operators (and restituted at the end, very
  similar to the "local" operator in Perl), you might perceive
  differences if your existing code relied on these implementation
  details (some test cases in the test suite of this package tested
  this and had therefore to be changed).

  The advantage to be gained by all this is that now, all modules
  in this package should be thread-safe and safe to be used by
  several concurrently executed modules, as long as you do not
  set the language using the global function "Language()" or the
  CLASS method "language()" (and as long as you do not use any
  other global setting, for that matter), but EXCLUSIVELY by
  passing the language parameter to all functions individually
  and by using the OBJECT method "language()".

  By exclusively using local settings, you are also making your
  code invulnerable against other, concurrent modules which still
  use global settings.

 -- Salvatore Bonaccorso <salvatore.bonaccorso@gmail.com>  Thu, 08 Oct 2009 22:28:18 +0200
