Fwd: Re: [rt.cpan.org #23307] YYYY-MM-DD HH:MM:SS not a valid datetime

2007-09-17 Thread Joshua Hoblitt
- Forwarded message from Michael G Schwern via RT [EMAIL PROTECTED] -

From: Michael G Schwern via RT [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Date: Mon, 17 Sep 2007 17:36:24 -0400
To: undisclosed-recipients: ;
Subject: Re: [rt.cpan.org #23307] -MM-DD HH:MM:SS not a valid datetime


   Queue: DateTime-Format-ISO8601
 Ticket URL: http://rt.cpan.org/Ticket/Display.html?id=23307 

Joshua Hoblitt via RT wrote:
 URL: http://rt.cpan.org/Ticket/Display.html?id=23307 
 
 I haven't given RFC 3339 an in depth study but it appears to be a
 significant simplification of ISO 8601:2000.  As you note, it's not
 really just a subset either as not all valid RFC 3339 formats are valid
 ISO 8601 formats because of the time  date separator relaxation.  It's
 also not clear to me if independent date or time formats are allowed.
 The ABNF is incorrect in that it doesn't allow for the space separator
 in place of T.

I noted that, too.  All of it's examples are full date times with the T 
separator.

The TAP datetime format gets around this by explicitly stating those
assumptions in it's grammar.

   tap_datetime= rfc_3339_date   rfc_3339_time   |
 rfc_3339_date |
 rfc_3339_time |
 rfc_3339_datetime
   rfc_3339_date   = As RFC 3339 section 5.6 full-date
   rfc_3339_time   = As RFC 3339 section 5.6 full-time
   rfc_3339_datetime   = As RFC 3339 section 5.6 date-time


 I would be tempted to make a parser for this RFC live in a new
 namespace, e.g.  DateTime::Format::RFC3339, regardless of how much code
 (and tests) are shared.  It probably makes sense to bundle it with
 DT:F::ISO8601 as well.

Yeah, that makes sense.


 How urgently do you need this?

Not urgently enough that I haven't gone and written it myself. :)  Just
thought I'd note it for the record as this issue keeps popping up.


-- 
Whip me, beat me, make my code compatible with VMS!


- End forwarded message -


pgpLJF0xDpc9n.pgp
Description: PGP signature


Re: [rt.cpan.org #23307] YYYY-MM-DD HH:MM:SS not a valid datetime

2007-09-17 Thread Joshua Hoblitt
I haven't given RFC 3339 an in depth study but it appears to be a
significant simplification of ISO 8601:2000.  As you note, it's not
really just a subset either as not all valid RFC 3339 formats are valid
ISO 8601 formats because of the time  date separator relaxation.  It's
also not clear to me if independent date or time formats are allowed.
The ABNF is incorrect in that it doesn't allow for the space separator
in place of T.

I would be tempted to make a parser for this RFC live in a new
namespace, e.g.  DateTime::Format::RFC3339, regardless of how much code
(and tests) are shared.  It probably makes sense to bundle it with
DT:F::ISO8601 as well.

How urgently do you need this?

Cheers,

-J

--
On Sun, Sep 16, 2007 at 06:04:20AM -0400, Michael G Schwern via RT wrote:
 
Queue: DateTime-Format-ISO8601
  Ticket URL: http://rt.cpan.org/Ticket/Display.html?id=23307 
 
 On Wed Nov 15 18:55:57 2006, JHOBLITT wrote:
  On Wed Nov 15 18:39:55 2006, [EMAIL PROTECTED] wrote:
   Well, it would be nice not to have to use an application specific date
  format parser for what is a very common mutation of the ISO8601
  format.  And then there's the DWIMness.  Maybe have a strict flag
  which can be turned on and off?
   
   Perhaps the place to do this is in the DateTime default format parser.
  
  I'm not sure if this parser should be pedantic or permissive by default
  since there are so many other general parsers already.  I'll float
  this issue on the datatime list and see what others think.
 
 So I have another need for this.  I need to be able to handle RFC 3339
 (simplified ISO 8601) which does allow a space.
 
   NOTE: ISO 8601 defines date and time separated by T.
   Applications using this syntax may choose, for the sake of
   readability, to specify a full-date and full-time separated by
   (say) a space character.
 
 TAP Datetime does just that.
 http://testanything.org/wiki/index.php/TAP_datetime
 
 Here's the options I see.
 
 1)  Make the ISO8601 parser permissive, or have a flag.
 2)  Change the stock DateTime parser to handle RFC 3339
 3)  Write an RFC3339 parser based on your ISO8601.
 
 They're not mutually exclusive, #3 can always be done.


pgpvEHCWdDBMj.pgp
Description: PGP signature


Re: Parsing LDAP Generalized Time with DateTime::Format::ISO8601

2007-05-11 Thread Joshua Hoblitt
On Sat, May 05, 2007 at 08:57:16PM -0700, Jonathan Leffler wrote:
 I can't answer for the developers of DateTime::Format::ISO8601, but it is 
 not clear that they are required to support the notation, though I suspect 
 it would not be hard to do so, possibly by some specialized sub-class 
 (Date::Format::LDAP?) that exploits the majority of the ISO8601 code but 
 permits the LDAP Generalized Time notation.

I can answer for the developer(s) of DateTime::Format::ISO8601.  Thus
far this module has only accepted a pretty strict interpretation of the
standard.  There have been a few requests to loosen to this up on the
basis of least surprise as some people have expected it to parse
things that look ISO8601 like.  However, there are already a large
number of swiss-army parsers that will handle ISO8601 like formats so
it was decided that DateTime::Format::ISO8601 should only accept formats
that are clearly allowed under the standard.  This allows the module to
be used as a validating parser.

I've looked at RFC 4517 and in section 3.3.13 it states that it does not
use a ISO8601 compliant format, The LDAP-specific encoding of a value
of this syntax is a restriction of the format defined in [ISO8601], and
is described by the following ABNF:   The format that is defined
looks fairly trivial to parse and I concur that it would be reasonable
to create a Date::Format::LDAP module.  Has anyone done this work
already?

-J

--


pgpr5A0Xe249B.pgp
Description: PGP signature


DateTime::Format::ISO8601 0.05 is borked!

2007-04-10 Thread Joshua Hoblitt
0.05 was supposed to be a very minor change over the previous release,
only disabling a single failing test.  Instead, 0.05 ended up being
based off my CVS head which hadn't had any of the changes on my 0.04
fixes branch merged into it.  In short, 0.05 is borked and is full of
serious regressions.  Do not use this release!

0.06 has just been sent to CPAN which incorporates all of the lost
changes between the 0.04  0.05 release.

0.05 has been scheduled to be removed from CPAN.

Ugh.

-J

--


pgpx90R3VYoNb.pgp
Description: PGP signature


is YYYY-MM-DD HH:MM:SS an ISO8601 format?

2006-11-15 Thread Joshua Hoblitt
Thoughts or comments on this bug that was just filed on DT::F::ISO8601
would be appreciated.  The summary: -MM-DD HH:MM:SS is not accept
by DT::F::ISO8601 and I don't believe it's a valid 8601 format.

http://rt.cpan.org//Ticket/Display.html?id=23307

-J

--


pgpzupHphCe99.pgp
Description: PGP signature


Re: Format::DateManip and Daylight Saving change

2006-10-05 Thread Joshua Hoblitt
On Thu, Oct 05, 2006 at 11:06:20AM +0100, David Cantrell wrote:
 Bill Moseley wrote:
 
 BTW:
 
 'print UnixDate(Dec 3, 2006 9am PST, %Z %Y %m %d %H %M %S %z  )'
 
 PDT 2006 12 03 10 00 00 -0700
 
 I believe that code like that should fail - or at least spit a warning - 
 as PST is ambiguous.  It's used in Pakistan and north America.  Yes, I 
 know it's documented, but really, who on earth checks the documentation 
 that carefully?  Ah well, at least they differ by a goodly amount so one 
 would hope the bug would be spotted.
 
 For more excitement, check out CST.  If you mean Cuba Summer Time but 
 actually get Central Standard Time they only differ by two hours, so the 
 bug is less likely to be spotted.
 
 Use of timezone abbreviations considered stupid.

I think that's a little harsh.  Abbreviations can certainly be useful
*in the context in which they were created*.  What your really complaining
about is bleed through from one regional context to another.  However,
I'd like to point on that this is really a complaint about the behavior
of Date::Manip as DateTime::Format::DateManip is really just a wrapper.
Since Date::Manip is so widely used there's not really much that can be
at this point without breaking a lot of code.  Perhaps warnings could
be issued on ambiguous TZ abbreviations stating the Olson name of the TZ
actually used but that is something that needs to be taken up with the
author of Date::Manip.  I also recommend that you to read the section of the
Date::Manip Pod titled SHOULD I USE DATE::MANIP.

Cheers,

-J

--


pgpc2jMVtPODQ.pgp
Description: PGP signature


Re: Parsing dates from 1955

2006-09-09 Thread Joshua Hoblitt
Eh, looks like SF's svn repo is down.

-J

--
On Sat, Sep 09, 2006 at 09:12:56AM -1000, Joshua Hoblitt wrote:
 I can confirm that a large number of tests are failing for me as well.
 Something has clearly change behavior.  Probably a local timezone issue.
 Are you 5 hours off UTC?
 
 -J
 
 --
 On Fri, Sep 08, 2006 at 07:14:10PM +0100, Simon Wistow wrote:
  There's a regression in a module of mine because one of the tests checks 
  to see that the string
  
  Sat, 12 November 1955 22:02:00
  
  can still be parsed and, er,r it can't any more.
  
  It used to work with Date::Parse (which relies on Time::Local AFAIK) 
  just fine.
  
  DateTime::Format::DateParse fails tests on my system with errors like
  
  t/03_getdateNOK 133
  #   Failed test '2002-11-07T23:31:49-05:00 0 0'
  #   in t/03_getdate.t at line 182.
  #  got: '2002-11-07T23:31:49'
  # expected: '2002-11-08T04:31:49'
  # Looks like you failed 103 tests of 135.
  t/03_getdatedubious
  Test returned status 103 (wstat 26368, 0x6700)
  DIED. FAILED tests 1-5, 9, 11, 13-17, 23-24, 27, 35-49, 51-80, 83-86, 
  89-95, 97-102, 105-122, 126-133
  Failed 103/135 tests, 23.70% okay (less 1 skipped test: 31 okay, 
  22.96%)
  Failed TestStat Wstat Total Fail  Failed  List of Failed
  ---
  t/03_getdate.t  103 26368   135  103  76.30%  1-5 9 11 13-17 23-24 27 
  35-49 51-
80 83-86 89-95 97-102 
  105-122
126-133
  
  
  Latest versions of DateTime, Date::Parse, Time::Local.
  
  [EMAIL PROTECTED] $ uname -a
  FreeBSD bacchus.thegestalt.org 6.1-RC FreeBSD 6.1-RC #0: Wed Apr 19 
  21:17:35 BST 2006 
  [EMAIL PROTECTED]:/usr/src/sys.exo/i386/compile/EXOJAIL  i386
  
  [EMAIL PROTECTED] $ perl -v
  
  This is perl, v5.8.8 built for i386-freebsd-64int
  (with 1 registered patch, see perl -V for more detail)
  
  Any ideas?
  
  Simon
  
  




pgpEdI04k5fpX.pgp
Description: PGP signature


Re: low-level date modules

2006-07-17 Thread Joshua Hoblitt
Is all that stuff just a reinvention of the wheel?  What's the value add
over DateTime and the zillions of other date/time modules already on CPAN?

I have to admit I haven't really looked at your code in depth but I
don't see how you can accurately be calculating TT/etc. without doing an
interpolation of IERS data.

If your interested in looking a working implementation of this I have one
in C as part of this library:

http://pan-starrs.ifa.hawaii.edu/project/IPP/software/pslib/

The relevant functions are documented here:


http://pan-starrs.ifa.hawaii.edu/project/IPP/software/pslib/pslib-0.12.0/doxygen/group__Time.html

(caution: not well tested)

-J

--
On Thu, Jun 15, 2006 at 09:42:45AM +0100, Zefram wrote:
 I've written a couple of Perl modules that do low-level date stuff,
 way below the high-level DateTime concept.  I'd appreciate a review
 of my modules by the date experts on this list.  The modules are
 Date::JD, which does conversions between several flavours of Julian
 Date, and Date::ISO8601, which implements the ISO 8601 calendrs in
 terms of Chronological Julian Day Numbers.  They can be found at
 http://search.cpan.org/~zefram/.  Thanks.
 
 -zefram


pgpVuHPEBqwr2.pgp
Description: PGP signature


Re: low-level date modules

2006-07-17 Thread Joshua Hoblitt
Oops - I made a typo.  Replace TT with UT1. (TT is trivial to calculate).

-J

--
On Sun, Jul 16, 2006 at 10:25:51PM -1000, Joshua Hoblitt wrote:
 Is all that stuff just a reinvention of the wheel?  What's the value add
 over DateTime and the zillions of other date/time modules already on CPAN?
 
 I have to admit I haven't really looked at your code in depth but I
 don't see how you can accurately be calculating TT/etc. without doing an
 interpolation of IERS data.
 
 If your interested in looking a working implementation of this I have one
 in C as part of this library:
 
 http://pan-starrs.ifa.hawaii.edu/project/IPP/software/pslib/
 
 The relevant functions are documented here:
 
 
 http://pan-starrs.ifa.hawaii.edu/project/IPP/software/pslib/pslib-0.12.0/doxygen/group__Time.html
 
 (caution: not well tested)
 
 -J
 
 --
 On Thu, Jun 15, 2006 at 09:42:45AM +0100, Zefram wrote:
  I've written a couple of Perl modules that do low-level date stuff,
  way below the high-level DateTime concept.  I'd appreciate a review
  of my modules by the date experts on this list.  The modules are
  Date::JD, which does conversions between several flavours of Julian
  Date, and Date::ISO8601, which implements the ISO 8601 calendrs in
  terms of Chronological Julian Day Numbers.  They can be found at
  http://search.cpan.org/~zefram/.  Thanks.
  
  -zefram




pgptXWBIt4iCh.pgp
Description: PGP signature


Re: low-level date modules

2006-07-17 Thread Joshua Hoblitt
On Mon, Jul 17, 2006 at 05:42:29PM +0100, Zefram wrote:
 There's leap seconds, but I presume that's intentional.  AFAIK DateTime
 operates correctly within its designed limits.

Entirely accidental, I assure you!   They are part of UTC.  Which in all
likely hood is what your system clock is synced with.  You have to
understand leapseconds in order to covert UTC to other time systems.
But you know this as you've had to implement leapseconds in
Time::UTC too.  What is the complaint here? DateTime.pm is not
the only DateTime compatible calendar.

 I think there'll be resolution issues, and possibly time-of-day model
 problems.  The biggest problem is the timezone stuff, though.  And, as I
 said, DateTime has no concept matching what a CJDN (or a JDN) represents.

Timezones are hard.  DateTime has gotten them more or less correct.

Uh, what about the -jd()  -mjd() DateTime.pm methods?

-J

--


pgpZ507Gj1YAt.pgp
Description: PGP signature


Re: low-level date modules

2006-07-17 Thread Joshua Hoblitt
On Mon, Jul 17, 2006 at 10:35:39PM +0100, Zefram wrote:
 Eugene van der Pijll wrote:
 For every future leap second, there will be a version of DT that
 handles it correctly. That the current implementation can not, is only
 an implentation problem :-).
 
 Having the implementation thus permanently buggy seems like a bad idea.
 Also, the version of DT that someone is using might not even know about
 leap seconds that have already happened.  You'll get different answers
 from different versions, not just at different times.

How is it buggy?  It is not possible to accurately determine that earths
rotational period that far into the future.

 Seriously, for problems like 2030-06-30T23:59:59Z + 1 second = ,
 you need to make an assumption about future leap seconds.
 
 I think the only correct approach is to assume nothing and answer I
 don't know.

So what are you proposing?  Modeling future leapseconds?  That would be
just as bad as there may never be another leapsecond.

I would really like to hear your solution to this problem.

-J

--


pgpmNGSIcPf0N.pgp
Description: PGP signature


Fwd: [PBP-pm] Working with dates

2005-12-21 Thread Joshua Hoblitt
- Forwarded message from Jay Buffington [EMAIL PROTECTED] -

From: Jay Buffington [EMAIL PROTECTED]
Date: Tue, 20 Dec 2005 21:27:31 -0800
To: Perl Best Practices [EMAIL PROTECTED]
Subject: [PBP-pm] Working with dates

Hi Everyone.

I'd like some feedback on best practices for working with dates in
perl.  Here's what I came up with:

Date Calculations
Use CPAN's Date::Calc to do any math or comparisons of dates. See
Date::Calc's recipes
(http://search.cpan.org/dist/Date-Calc/Calc.pod#RECIPES) section for
more examples.

Example:
Determine if today date is between Dec. 12th, 2005 and Dec. 19th, 2005
(inclusive):

use Date::Calc qw( Date_to_Days Today );

my $lower = Date_to_Days(2005, 12, 12);
my $upper = Date_to_Days(2005, 12, 19);

my $date = Date_to_Days(Today());

if (($date = $lower)  ($date = $upper)) {
   print Today is between Dec. 12th and Dec. 19th!\n;
}


Returning Dates from Functions
Functions or methods that need to return a date should return them in
a hash reference using the same format the DateTime module takes as
input.

Example:
Return a date that represents Tue Dec 15 19:23:45 PST 2005

return  {
   year  = 2005,
   month = 12,
   day   = 15,
   hour  = 19,
   minute= 23,
   second= 45,
   time_zone = '+0800',
 };


Displaying Dates
Use CPAN's DateTime to format dates for display.

Example:
Print the date a file was uploaded as a RFC822-conformant date

use DateTime;

my $date = $file-get_upload_date();
my $dt = new DateTime( %{ $date } );
# `perldoc DateTime` for all format specifiers
print $dt-strftime('%a, %d %b %Y %H:%M:%S %z');
___
PBP-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman/listinfo/pbp-pm

- End forwarded message -


pgpHTiTPeEDW4.pgp
Description: PGP signature


Fwd: Unable to install DateTime::Format::DateParse in Windows

2005-10-29 Thread Joshua Hoblitt
Any ideas as to what's going on with parsing Pod on win32?

Thanks,

-J

--
- Forwarded message from Jim Lancaster [EMAIL PROTECTED] -

From: Jim Lancaster [EMAIL PROTECTED]
Date: Fri, 28 Oct 2005 21:01:58 -0500
To: [EMAIL PROTECTED]
Subject: Unable to install DateTime::Format::DateParse in Windows

Is there a work around? 

Thanks,

Jim Lancaster
[EMAIL PROTECTED]

This is the error I'm getting:
 
cpan force install DateTime::Format::DateParse
Running install for module DateTime::Format::DateParse
Running make for J/JH/JHOBLITT/DateTime-Format-DateParse-0.02.tar.gz
Checksum for
\.cpan\sources\authors\id\J\JH\JHOBLITT\DateTime-Format-DateParse-0
.02.tar.gz ok
DateTime-Format-DateParse-0.02/
DateTime-Format-DateParse-0.02/lib/
DateTime-Format-DateParse-0.02/lib/DateTime/
DateTime-Format-DateParse-0.02/lib/DateTime/Format/
DateTime-Format-DateParse-0.02/lib/DateTime/Format/DateParse.pm
DateTime-Format-DateParse-0.02/lib/DateTime/Format/DateParse.pod
DateTime-Format-DateParse-0.02/README
DateTime-Format-DateParse-0.02/Build.PL
DateTime-Format-DateParse-0.02/Changes
DateTime-Format-DateParse-0.02/LICENSE
DateTime-Format-DateParse-0.02/MANIFEST
DateTime-Format-DateParse-0.02/META.yml
DateTime-Format-DateParse-0.02/t/
DateTime-Format-DateParse-0.02/t/03_getdate.t
DateTime-Format-DateParse-0.02/t/01_load.t
DateTime-Format-DateParse-0.02/t/02_date.t
DateTime-Format-DateParse-0.02/Makefile.PL
Removing previously used \.cpan\build\DateTime-Format-DateParse-0.02
 
  CPAN.pm: Going to build
J/JH/JHOBLITT/DateTime-Format-DateParse-0.02.tar.gz
 
# running Build.PL
C:\Perl\bin\perl.exe -I_build/lib Build.PL
Checking whether your kit is complete...
Looks good
Creating new 'Build' script for 'DateTime-Format-DateParse' version
'0.02'
 
Microsoft (R) Program Maintenance Utility   Version 1.50
Copyright (c) Microsoft Corp 1988-94. All rights reserved.
 
C:\Perl\bin\perl.exe Build --makefile_env_macros 1
lib\DateTime\Format\DateParse.pm -
blib\lib\DateTime\Format\DateParse.pm
lib\DateTime\Format\DateParse.pod -
blib\lib\DateTime\Format\DateParse.pod
Manifying blib\lib/DateTime/Format/DateParse.pod -
blib\libdoc\DateTime.Format.
DateParse.3
HTMLifying blib\lib/DateTime/Format/DateParse.pod -
blib/html/site/lib/DateTime
/Format/DateParse.html
Build: blib\lib/DateTime/Format/DateParse.pod: cannot resolve
LDateTime in par
agraph 17.
Build: blib\lib/DateTime/Format/DateParse.pod: cannot resolve
LDateTime in par
agraph 21.
Build: blib\lib/DateTime/Format/DateParse.pod: cannot resolve
LDateTime in par
agraph 22.
Build: blib\lib/DateTime/Format/DateParse.pod: cannot resolve
Lperlartistic in
 paragraph 33.
Build: blib\lib/DateTime/Format/DateParse.pod: cannot resolve Lperlgpl
in para
graph 33.
Build: blib\lib/DateTime/Format/DateParse.pod: cannot resolve
LDateTime in par
agraph 35.
  c:\cygwin\bin\nmake.exe  -- OK
Running make test
 
Microsoft (R) Program Maintenance Utility   Version 1.50
Copyright (c) Microsoft Corp 1988-94. All rights reserved.
 
C:\Perl\bin\perl.exe Build --makefile_env_macros 1 test
t\01_load...
t\01_load...NOK 1# Failed test (t\01_load.t at line 10)
# Tried to use 'DateTime::Format::DateParse'.
# Error:  Can't locate Date/Parse.pm in @INC (@INC contains: ./lib
C:\.cpan\
build\DateTime-Format-DateParse-0.02\blib\lib
C:\.cpan\build\DateTime-Format-Dat
eParse-0.02\blib\arch
C:\.cpan\build\DateTime-Format-DateParse-0.02\_build\lib C
:/Perl/lib C:/Perl/site/lib .) at lib/DateTime/Format/DateParse.pm line
14.
# BEGIN failed--compilation aborted at t\01_load.t line 10.
# Compilation failed in require at (eval 3) line 2.
# BEGIN failed--compilation aborted at (eval 3) line 2.
# Looks like you failed 1 test of 1.
t\01_load...dubious
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 1
Failed 1/1 tests, 0.00% okay
t\02_date...Can't locate Date/Parse.pm in @INC (@INC contains: ./lib
C:\.cpa
n\build\DateTime-Format-DateParse-0.02\blib\lib
C:\.cpan\build\DateTime-Format-D
ateParse-0.02\blib\arch
C:\.cpan\build\DateTime-Format-DateParse-0.02\_build\lib
 C:/Perl/lib C:/Perl/site/lib .) at lib/DateTime/Format/DateParse.pm
line 14.
BEGIN failed--compilation aborted at lib/DateTime/Format/DateParse.pm
line 14.
Compilation failed in require at t\02_date.t line 12.
BEGIN failed--compilation aborted at t\02_date.t line 12.
t\02_date...dubious
Test returned status 2 (wstat 512, 0x200)
t\03_getdateCan't locate Date/Parse.pm in @INC (@INC contains: ./lib
C:\.cpa
n\build\DateTime-Format-DateParse-0.02\blib\lib
C:\.cpan\build\DateTime-Format-D
ateParse-0.02\blib\arch
C:\.cpan\build\DateTime-Format-DateParse-0.02\_build\lib
 C:/Perl/lib C:/Perl/site/lib .) at lib/DateTime/Format/DateParse.pm
line 14.
BEGIN failed--compilation aborted at lib/DateTime/Format/DateParse.pm
line 14.
Compilation failed in require at t\03_getdate.t line 13.
BEGIN failed--compilation aborted at t\03_getdate.t line 13.
t\03_getdatedubious
Test returned status 

Re: RT::Date::Set ISO format error while updated to 5.8.6

2005-10-25 Thread Joshua Hoblitt
You've got the wrong suspects.  RT::Date is part of the RT product.

http://www.bestpractical.com/rt/

There are instructions on where to send a bug report here:

http://rt3.fsck.com//NoAuth/Buglist.html

Cheers,

-J

--
On Wed, Oct 19, 2005 at 12:24:53AM -0700, wk.Fung wrote:
 
 Hi,
 
 Please forgive me if I've wrongly posted the message.
 
 I've encountered some difficulties while moving my program from FC2 to
 FC4. And it happens to have the following errors ...
 
 I've googled it and some people has mentioned that the wrong ISO format
 triggered this error. But I question is, it used to work before Perl
 version 5.8.6. I don't get it why this time it couldn't work.
 
 Oct 17 17:20:02 FC4 RT:  at /usr/local/rt3/lib/RT/Date.pm line 170
 RT::Date::Set('RT::Date=HASH(0xacde74c)', 'Format', 'ISO', 'Value',
 1129540502) called at /usr/local/rt3/bin/create_incident line 85
 (/usr/local/rt3/lib/RT.pm:248)
 
 # in /usr/local/rt3/bin/create_incident
 my $now = new RT::Date($RT::SystemUser);
 $now-SetToNow();
 my $date = new RT::Date($RT::SystemUser);
 my $timeFrom = new RT::Date($RT::SystemUser);
 open(FILE, /var/log/myerror.log);
 print FILE 1 TimeFrom:  . $timeFrom . \n;
 $timeFrom - Set(Format = 'ISO', Value= $now- ISO);
 print FILE 2 TimeFrom:  . $timeFrom . \n;
 $timeFrom - Set(Format = 'ISO', Value= $timeFrom-
 SubtractSeconds($timeInterval));  # line 85
 print FILE 3 TimeFrom:  . $timeFrom . \n;
 close FILE;
 
 # dumped message from myerror.log
 1 TimeFrom: RT::Date=HASH(0x997874c)
 2 TimeFrom: RT::Date=HASH(0x997874c)
 3 TimeFrom: RT::Date=HASH(0x997874c)
 
 Can someone please comment on it?
 
 Thanks,
 
 -Eric.
 


pgpGbjhlJ4Q13.pgp
Description: PGP signature


Re: DateTime.pm 0.30 coming up real soon now

2005-09-07 Thread Joshua Hoblitt
On Tue, Sep 06, 2005 at 09:57:11AM -0500, Dave Rolsky wrote:
 On Mon, 5 Sep 2005, Joshua Hoblitt wrote:
 If I understand you correctly, your position is that user's will be
 confused by DST transitions screwing up additions but won't notice the
 same effect on subtractions?
 
 No, they'll notice, but the workarounds for subtractions are 
 well-documented.

So why is that better than making subtractions work 'as expected' and
documenting the work arounds for addition?

 Anyway, your position seemed to be that they won't notice for either, and 
 that both should be weird ;)

My position is that you really need to put on your critical thinking hat
and think about how *wrong* it is for additions and subtractions to have
different behaviors.

 The more I think about this the more I'm convinced that the idea of 
 datetime subtraction producing something other than seconds is a 
 convenient fiction.  Similarly, date subtraction producing something other 
 than a count of days is full of potential bugs.

The whole point of DT is that it is *correct*.  We need to decide on
what the correct behavior is regardless of how painful it is to
implement on top of the Rata Die system.  It seems to me the real
question would should be answering is: is calendar math subject to DST
transitions or not?

-J

--


pgpIFCtNBcCT9.pgp
Description: PGP signature


Re: DateTime.pm 0.30 coming up real soon now

2005-09-06 Thread Joshua Hoblitt
On Mon, Sep 05, 2005 at 03:15:35PM -0500, Dave Rolsky wrote:
 This means that if you do subtract_datetime on two objects you end up with 
 this situation:
 
   $dur = $dt2 - $dt1
   $dt1 + $dur != $dt2
   $dt2 - $dur != $dt1
 
 But honestly I don't really think that's a bug, and it's covered in the 
 docs.

I think that behavior would merely be a documented bug and worse a
support nightmare.  I can not logically grasp how the internal between
two known fixed points on a continuing would have not have a well known
distance between them.

Won't forcing add_duation() to convert to UTC resolve this
inconsistency?

-J

--


pgppWjabm1uPy.pgp
Description: PGP signature


Re: DateTime.pm 0.30 coming up real soon now

2005-09-06 Thread Joshua Hoblitt
On Mon, Sep 05, 2005 at 11:49:33PM -0500, Dave Rolsky wrote:
   my $dt = DateTime-new( year = 2003, month = 9, time_zone = 
   'America/Chicago' );
   $dt-add( months = 3 );
 
 Now what do you expect that to produce?  I suspect 99% of users expect 
 that to produce 2003-12-01T00:00:00.  In other words, we take month 9, 
 add 3, and get 12.  The time remains untouched.
 
 But if add_duration did the math on the UTC portions it'd give you 
 2003-11-30T23:00:00.

If I understand you correctly, your position is that user's will be
confused by DST transitions screwing up additions but won't notice the
same effect on subtractions?

-J

--


pgpBdDrTSMYPC.pgp
Description: PGP signature


Re: hires DateTime-from_epoch( epoch = ... ) values

2005-08-09 Thread Joshua Hoblitt
On Mon, Aug 08, 2005 at 10:45:19AM -0500, Dave Rolsky wrote:
 On Mon, 8 Aug 2005, John Siracusa wrote:
 
 On 8/8/05, Dave Rolsky [EMAIL PROTECTED] wrote:
 Does anyone object to adding Math::BigFloat as a
 prereq?
 
 What are the performance/memory implications?  I don't object to the 
 prereq,
 but I would like to know if we're in for any new speed/bloat issues.  (I
 only really care about per-object overhead, not the cost of loading
 Math::BigFloat itself.)
 
 If I read the patch directly, we never store the bigfloat object, we just 
 use it to make sure that nanoseconds has the right value.

That's correct.  A single Math::BigFloat object is used as an
intermediate value, to hold the hires epoch 'string', which is then
immediately discarded after seperating the integer and fractional
values.

It shouldn't have much impact on memory unless Math::BigFloat has leaks.
;)

Cheers,

-J

--


pgpEitMgczkpC.pgp
Description: PGP signature


Re: hires DateTime-from_epoch( epoch = ... ) values

2005-08-09 Thread Joshua Hoblitt
On Mon, Aug 08, 2005 at 09:02:06AM -1000, Joshua Hoblitt wrote:
 On Mon, Aug 08, 2005 at 10:45:19AM -0500, Dave Rolsky wrote:
  On Mon, 8 Aug 2005, John Siracusa wrote:
  
  On 8/8/05, Dave Rolsky [EMAIL PROTECTED] wrote:
  Does anyone object to adding Math::BigFloat as a
  prereq?
  
  What are the performance/memory implications?  I don't object to the 
  prereq,
  but I would like to know if we're in for any new speed/bloat issues.  (I
  only really care about per-object overhead, not the cost of loading
  Math::BigFloat itself.)
  
  If I read the patch directly, we never store the bigfloat object, we just 
  use it to make sure that nanoseconds has the right value.
 
 That's correct.  A single Math::BigFloat object is used as an
 intermediate value, to hold the hires epoch 'string', which is then
 immediately discarded after seperating the integer and fractional
 values.
 
 It shouldn't have much impact on memory unless Math::BigFloat has leaks.
 ;)

On second thought, would we be better off simplifying
DateTime::from_epoch to only handle integer values and move all the
floating point complexity into DateTime::HiRes?  That would be
optimizing the common case.

Cheers,

-J

--


pgpivzyAm7UOQ.pgp
Description: PGP signature


Re: hires DateTime-from_epoch( epoch = ... ) values

2005-08-08 Thread Joshua Hoblitt
Since nobody has commented on this patch does that mean everybody agrees
that it's a good idea? :)

-J

--
On Mon, Jul 25, 2005 at 04:10:53PM -1000, Joshua Hoblitt wrote:
 Hi Folks,
 
 I stumbled across a limited precision issue while working on
 DateTime::Format::DateParse.
 
 One of 'epoch' test values used in Date::Parse is 1045469647.198189,
 which is just beyond the precision of an IEEE 754 64bit value (a C
 double).  So internally (on all IEEE 754 compliant platforms, YMMV) this
 gets represent as 1045469647.198189020... .  Since
 DateTime-from_epoch() treats the epoch parameter as numeric, it
 currently creates an object from that number set to 198_189_020
 nanoseconds.  I believe that this is surprising behavior for most users;
 in general people don't think about using an epsilon when comparing
 integer values.
 
 Possible solutions:
 
 a) do nothing... nobody else seems to have noticed
 b) document the limited precision issue
 c) change the API to some awful Fortranish a part + b part to preserve
 precision
 d) turn the epoch parameter into a Math::BigFloat so a high resolution
 'string' can be passed in and document the behavior.
 
 It's not clear to me what the right solution is although a patch to
 implement option d sans the required documentation changes is attached.
 
 Cheers,
 
 -J
 
 --

 ? .swp
 ? DateTime-0.2901-from_epoch_precision-fix.patch
 ? DateTime.bs
 ? DateTime.c
 ? Makefile
 ? blib
 ? leap_seconds.h
 ? pm_to_blib
 ? tmp.pl
 ? t/zz_00load.t
 ? t/zz_01sanity.t
 ? t/zz_02last_day.t
 ? t/zz_03components.t
 ? t/zz_04epoch.t
 ? t/zz_05set.t
 ? t/zz_06add.t
 ? t/zz_07compare.t
 ? t/zz_09greg.t
 ? t/zz_10subtract.t
 ? t/zz_11duration.t
 ? t/zz_12week.t
 ? t/zz_13strftime.t
 ? t/zz_14locale.t
 ? t/zz_15jd.t
 ? t/zz_16truncate.t
 ? t/zz_17set_return.t
 ? t/zz_18today.t
 ? t/zz_19leap_second.t
 ? t/zz_20infinite.t
 ? t/zz_21bad_params.t
 ? t/zz_22from_doy.t
 ? t/zz_23storable.t
 ? t/zz_24from_object.t
 ? t/zz_25add_subtract.t
 ? t/zz_27delta.t
 ? t/zz_28dow.t
 ? t/zz_29overload.t
 ? t/zz_30future_tz.t
 ? t/zz_31formatter.t
 ? t/zz_32leap_second2.t
 ? t/zz_33seconds_offset.t
 ? t/zz_34set_tz.t
 ? t/zz_35rd_values.t
 ? t/zz_36invalid_local.t
 Index: Makefile.PL
 ===
 RCS file: /cvsroot/perl-date-time/modules/DateTime.pm/Makefile.PL,v
 retrieving revision 1.47
 diff -u -r1.47 Makefile.PL
 --- Makefile.PL   27 Feb 2005 03:27:25 -  1.47
 +++ Makefile.PL   26 Jul 2005 01:41:35 -
 @@ -83,6 +83,7 @@
  
 PREREQ_PM= { 'DateTime::Locale' = 0.21,
   'DateTime::TimeZone' = 0.26,
 + 'Math::BigFloat' = 0,
   'Params::Validate' = 0.76,
   'Pod::Man'= 1.14,
   'Test::More'  = 0.34,
 Index: lib/DateTime.pm
 ===
 RCS file: /cvsroot/perl-date-time/modules/DateTime.pm/lib/DateTime.pm,v
 retrieving revision 1.304
 diff -u -r1.304 DateTime.pm
 --- lib/DateTime.pm   7 Jul 2005 23:18:21 -   1.304
 +++ lib/DateTime.pm   26 Jul 2005 01:41:38 -
 @@ -48,6 +48,7 @@
  use DateTime::TimeZone;
  use Params::Validate qw( validate validate_pos SCALAR BOOLEAN HASHREF OBJECT 
 );
  use Time::Local ();
 +use Math::BigFloat;
  
  # for some reason, overloading doesn't work unless fallback is listed
  # early.
 @@ -435,8 +436,8 @@
  my %args;
  
  # Because epoch may come from Time::HiRes
 -my $fraction = $p{epoch} - int( $p{epoch} );
 -$args{nanosecond} = int( $fraction * MAX_NANOSECONDS )
 +my $fraction = Math::BigFloat-new( $p{epoch} ) - int( $p{epoch} );
 +$args{nanosecond} = int ( $fraction * MAX_NANOSECONDS )-as_int-bstr
  if $fraction;
  
  # Note, for very large negative values this may give a blatantly
 Index: t/04epoch.t
 ===
 RCS file: /cvsroot/perl-date-time/modules/DateTime.pm/t/04epoch.t,v
 retrieving revision 1.18
 diff -u -r1.18 04epoch.t
 --- t/04epoch.t   13 Nov 2004 21:22:36 -  1.18
 +++ t/04epoch.t   26 Jul 2005 01:41:38 -
 @@ -2,7 +2,7 @@
  
  use strict;
  
 -use Test::More tests = 32;
 +use Test::More tests = 34;
  
  use DateTime;
  
 @@ -126,3 +126,13 @@
  my $dt = DateTime-from_epoch( epoch = 0.1234567891 );
  is( $dt-nanosecond, 123_456_789, 'nanosecond should be an integer ' );
  }
 +
 +{
 +my $dt = DateTime-from_epoch( epoch = 123456789.1234567891 );
 +is( $dt-nanosecond, 123_456_789, 'nanosecond should be an integer ' );
 +}
 +
 +{
 +my $dt = DateTime-from_epoch( epoch = 1045469647.198189 );
 +is( $dt-nanosecond, 198_189_000, 'nanosecond should be an integer ' );
 +}





pgphQzDt5zeaD.pgp
Description: PGP signature


[announce] DateTime::Format::DateParse 0.02

2005-08-08 Thread Joshua Hoblitt
Released to CPAN (a couple of weeks ago).

Please be sure to check the GOTCHAS section of the Pod before using it:


http://search.cpan.org/~jhoblitt/DateTime-Format-DateParse-0.02/lib/DateTime/Format/DateParse.pod#GOTCHAS

Cheers,

-J

--


pgpB2ye2kBPcc.pgp
Description: PGP signature


[announce] DateTime::Format::ISO8601 0.0403

2005-08-08 Thread Joshua Hoblitt
The 'Al might be a whiner' release.

Released to CPAN.

Changes since 0.0402

- update doc format
- tidy Build.PL
- auto-generate Makefile.PL
- change set_base_datetime() to use DT's overloaded = instead of
  -compare()
- tidy test sources and reduce runtime

Cheers,

-J

--


pgp62mojsubeJ.pgp
Description: PGP signature


Re: hires DateTime-from_epoch( epoch = ... ) values

2005-07-26 Thread Joshua Hoblitt
Here's a quick demonstration of the issue...

--
#!/usr/bin/perl

use Math::BigFloat;
use Math::BigInt;

myfunc(1045469647.198189);
myfunc('1045469647.198189');

sub myfunc {
my $n = shift;

my $fraction = Math::BigFloat-new( $n ) - int( $n );

printf %s\n, int ( $fraction * 1e9 )-as_int-bstr;
}
--

-J

--
On Mon, Jul 25, 2005 at 04:10:53PM -1000, Joshua Hoblitt wrote:
 Hi Folks,
 
 I stumbled across a limited precision issue while working on
 DateTime::Format::DateParse.
 
 One of 'epoch' test values used in Date::Parse is 1045469647.198189,
 which is just beyond the precision of an IEEE 754 64bit value (a C
 double).  So internally (on all IEEE 754 compliant platforms, YMMV) this
 gets represent as 1045469647.198189020... .  Since
 DateTime-from_epoch() treats the epoch parameter as numeric, it
 currently creates an object from that number set to 198_189_020
 nanoseconds.  I believe that this is surprising behavior for most users;
 in general people don't think about using an epsilon when comparing
 integer values.
 
 Possible solutions:
 
 a) do nothing... nobody else seems to have noticed
 b) document the limited precision issue
 c) change the API to some awful Fortranish a part + b part to preserve
 precision
 d) turn the epoch parameter into a Math::BigFloat so a high resolution
 'string' can be passed in and document the behavior.
 
 It's not clear to me what the right solution is although a patch to
 implement option d sans the required documentation changes is attached.
 
 Cheers,
 
 -J
 
 --

 ? .swp
 ? DateTime-0.2901-from_epoch_precision-fix.patch
 ? DateTime.bs
 ? DateTime.c
 ? Makefile
 ? blib
 ? leap_seconds.h
 ? pm_to_blib
 ? tmp.pl
 ? t/zz_00load.t
 ? t/zz_01sanity.t
 ? t/zz_02last_day.t
 ? t/zz_03components.t
 ? t/zz_04epoch.t
 ? t/zz_05set.t
 ? t/zz_06add.t
 ? t/zz_07compare.t
 ? t/zz_09greg.t
 ? t/zz_10subtract.t
 ? t/zz_11duration.t
 ? t/zz_12week.t
 ? t/zz_13strftime.t
 ? t/zz_14locale.t
 ? t/zz_15jd.t
 ? t/zz_16truncate.t
 ? t/zz_17set_return.t
 ? t/zz_18today.t
 ? t/zz_19leap_second.t
 ? t/zz_20infinite.t
 ? t/zz_21bad_params.t
 ? t/zz_22from_doy.t
 ? t/zz_23storable.t
 ? t/zz_24from_object.t
 ? t/zz_25add_subtract.t
 ? t/zz_27delta.t
 ? t/zz_28dow.t
 ? t/zz_29overload.t
 ? t/zz_30future_tz.t
 ? t/zz_31formatter.t
 ? t/zz_32leap_second2.t
 ? t/zz_33seconds_offset.t
 ? t/zz_34set_tz.t
 ? t/zz_35rd_values.t
 ? t/zz_36invalid_local.t
 Index: Makefile.PL
 ===
 RCS file: /cvsroot/perl-date-time/modules/DateTime.pm/Makefile.PL,v
 retrieving revision 1.47
 diff -u -r1.47 Makefile.PL
 --- Makefile.PL   27 Feb 2005 03:27:25 -  1.47
 +++ Makefile.PL   26 Jul 2005 01:41:35 -
 @@ -83,6 +83,7 @@
  
 PREREQ_PM= { 'DateTime::Locale' = 0.21,
   'DateTime::TimeZone' = 0.26,
 + 'Math::BigFloat' = 0,
   'Params::Validate' = 0.76,
   'Pod::Man'= 1.14,
   'Test::More'  = 0.34,
 Index: lib/DateTime.pm
 ===
 RCS file: /cvsroot/perl-date-time/modules/DateTime.pm/lib/DateTime.pm,v
 retrieving revision 1.304
 diff -u -r1.304 DateTime.pm
 --- lib/DateTime.pm   7 Jul 2005 23:18:21 -   1.304
 +++ lib/DateTime.pm   26 Jul 2005 01:41:38 -
 @@ -48,6 +48,7 @@
  use DateTime::TimeZone;
  use Params::Validate qw( validate validate_pos SCALAR BOOLEAN HASHREF OBJECT 
 );
  use Time::Local ();
 +use Math::BigFloat;
  
  # for some reason, overloading doesn't work unless fallback is listed
  # early.
 @@ -435,8 +436,8 @@
  my %args;
  
  # Because epoch may come from Time::HiRes
 -my $fraction = $p{epoch} - int( $p{epoch} );
 -$args{nanosecond} = int( $fraction * MAX_NANOSECONDS )
 +my $fraction = Math::BigFloat-new( $p{epoch} ) - int( $p{epoch} );
 +$args{nanosecond} = int ( $fraction * MAX_NANOSECONDS )-as_int-bstr
  if $fraction;
  
  # Note, for very large negative values this may give a blatantly
 Index: t/04epoch.t
 ===
 RCS file: /cvsroot/perl-date-time/modules/DateTime.pm/t/04epoch.t,v
 retrieving revision 1.18
 diff -u -r1.18 04epoch.t
 --- t/04epoch.t   13 Nov 2004 21:22:36 -  1.18
 +++ t/04epoch.t   26 Jul 2005 01:41:38 -
 @@ -2,7 +2,7 @@
  
  use strict;
  
 -use Test::More tests = 32;
 +use Test::More tests = 34;
  
  use DateTime;
  
 @@ -126,3 +126,13 @@
  my $dt = DateTime-from_epoch( epoch = 0.1234567891 );
  is( $dt-nanosecond, 123_456_789, 'nanosecond should be an integer ' );
  }
 +
 +{
 +my $dt = DateTime-from_epoch( epoch = 123456789.1234567891 );
 +is( $dt-nanosecond, 123_456_789, 'nanosecond should be an integer ' );
 +}
 +
 +{
 +my $dt = DateTime-from_epoch( epoch = 1045469647.198189

hires DateTime-from_epoch( epoch = ... ) values

2005-07-26 Thread Joshua Hoblitt
Hi Folks,

I stumbled across a limited precision issue while working on
DateTime::Format::DateParse.

One of 'epoch' test values used in Date::Parse is 1045469647.198189,
which is just beyond the precision of an IEEE 754 64bit value (a C
double).  So internally (on all IEEE 754 compliant platforms, YMMV) this
gets represent as 1045469647.198189020... .  Since
DateTime-from_epoch() treats the epoch parameter as numeric, it
currently creates an object from that number set to 198_189_020
nanoseconds.  I believe that this is surprising behavior for most users;
in general people don't think about using an epsilon when comparing
integer values.

Possible solutions:

a) do nothing... nobody else seems to have noticed
b) document the limited precision issue
c) change the API to some awful Fortranish a part + b part to preserve
precision
d) turn the epoch parameter into a Math::BigFloat so a high resolution
'string' can be passed in and document the behavior.

It's not clear to me what the right solution is although a patch to
implement option d sans the required documentation changes is attached.

Cheers,

-J

--
? .swp
? DateTime-0.2901-from_epoch_precision-fix.patch
? DateTime.bs
? DateTime.c
? Makefile
? blib
? leap_seconds.h
? pm_to_blib
? tmp.pl
? t/zz_00load.t
? t/zz_01sanity.t
? t/zz_02last_day.t
? t/zz_03components.t
? t/zz_04epoch.t
? t/zz_05set.t
? t/zz_06add.t
? t/zz_07compare.t
? t/zz_09greg.t
? t/zz_10subtract.t
? t/zz_11duration.t
? t/zz_12week.t
? t/zz_13strftime.t
? t/zz_14locale.t
? t/zz_15jd.t
? t/zz_16truncate.t
? t/zz_17set_return.t
? t/zz_18today.t
? t/zz_19leap_second.t
? t/zz_20infinite.t
? t/zz_21bad_params.t
? t/zz_22from_doy.t
? t/zz_23storable.t
? t/zz_24from_object.t
? t/zz_25add_subtract.t
? t/zz_27delta.t
? t/zz_28dow.t
? t/zz_29overload.t
? t/zz_30future_tz.t
? t/zz_31formatter.t
? t/zz_32leap_second2.t
? t/zz_33seconds_offset.t
? t/zz_34set_tz.t
? t/zz_35rd_values.t
? t/zz_36invalid_local.t
Index: Makefile.PL
===
RCS file: /cvsroot/perl-date-time/modules/DateTime.pm/Makefile.PL,v
retrieving revision 1.47
diff -u -r1.47 Makefile.PL
--- Makefile.PL 27 Feb 2005 03:27:25 -  1.47
+++ Makefile.PL 26 Jul 2005 01:41:35 -
@@ -83,6 +83,7 @@
 
PREREQ_PM= { 'DateTime::Locale' = 0.21,
  'DateTime::TimeZone' = 0.26,
+ 'Math::BigFloat' = 0,
  'Params::Validate' = 0.76,
  'Pod::Man'= 1.14,
  'Test::More'  = 0.34,
Index: lib/DateTime.pm
===
RCS file: /cvsroot/perl-date-time/modules/DateTime.pm/lib/DateTime.pm,v
retrieving revision 1.304
diff -u -r1.304 DateTime.pm
--- lib/DateTime.pm 7 Jul 2005 23:18:21 -   1.304
+++ lib/DateTime.pm 26 Jul 2005 01:41:38 -
@@ -48,6 +48,7 @@
 use DateTime::TimeZone;
 use Params::Validate qw( validate validate_pos SCALAR BOOLEAN HASHREF OBJECT );
 use Time::Local ();
+use Math::BigFloat;
 
 # for some reason, overloading doesn't work unless fallback is listed
 # early.
@@ -435,8 +436,8 @@
 my %args;
 
 # Because epoch may come from Time::HiRes
-my $fraction = $p{epoch} - int( $p{epoch} );
-$args{nanosecond} = int( $fraction * MAX_NANOSECONDS )
+my $fraction = Math::BigFloat-new( $p{epoch} ) - int( $p{epoch} );
+$args{nanosecond} = int ( $fraction * MAX_NANOSECONDS )-as_int-bstr
 if $fraction;
 
 # Note, for very large negative values this may give a blatantly
Index: t/04epoch.t
===
RCS file: /cvsroot/perl-date-time/modules/DateTime.pm/t/04epoch.t,v
retrieving revision 1.18
diff -u -r1.18 04epoch.t
--- t/04epoch.t 13 Nov 2004 21:22:36 -  1.18
+++ t/04epoch.t 26 Jul 2005 01:41:38 -
@@ -2,7 +2,7 @@
 
 use strict;
 
-use Test::More tests = 32;
+use Test::More tests = 34;
 
 use DateTime;
 
@@ -126,3 +126,13 @@
 my $dt = DateTime-from_epoch( epoch = 0.1234567891 );
 is( $dt-nanosecond, 123_456_789, 'nanosecond should be an integer ' );
 }
+
+{
+my $dt = DateTime-from_epoch( epoch = 123456789.1234567891 );
+is( $dt-nanosecond, 123_456_789, 'nanosecond should be an integer ' );
+}
+
+{
+my $dt = DateTime-from_epoch( epoch = 1045469647.198189 );
+is( $dt-nanosecond, 198_189_000, 'nanosecond should be an integer ' );
+}


pgp0UXq4Jq4m6.pgp
Description: PGP signature


Re: questions about DateTime::Locale internal structure

2005-07-25 Thread Joshua Hoblitt
-J

--
On Sat, Jul 23, 2005 at 11:06:23PM -1000, Joshua Hoblitt wrote:
 On Sun, Jul 24, 2005 at 02:30:54PM +0900, Daisuke Maki wrote:
- Is there any reason why the locales are not singletons?
 
 None that I can think of.
 
- Can I make them singleton?
 
 Locale objects are cached during 'load' so that the same object may be
 shared between multiple DTs.  This cache gets dumped when: a new locale
 is registered, an alias is added, an alias is removed.  So it may very
 well be a win to make DateTime::Locale objects true singletons but you
 probably won't notice a difference unless your screwing around with
 custom locales.
 
 You might want to seek Dave's opinion before putting effort into a
 patch.
 
- Can I make parameters like en_language, en_territory,
  en_complete_name, et al class variables, and do away with any instance
  variables?
 
 That data needs to be unique per locale object.

Err, I ment to say that data needs to be unique per locale class but is
this really a win if there is only one instance per class?

-J

--


pgpEC2J6D2VIs.pgp
Description: PGP signature


Re: questions about DateTime::Locale internal structure

2005-07-24 Thread Joshua Hoblitt
On Sun, Jul 24, 2005 at 02:30:54PM +0900, Daisuke Maki wrote:
   - Is there any reason why the locales are not singletons?

None that I can think of.

   - Can I make them singleton?

Locale objects are cached during 'load' so that the same object may be
shared between multiple DTs.  This cache gets dumped when: a new locale
is registered, an alias is added, an alias is removed.  So it may very
well be a win to make DateTime::Locale objects true singletons but you
probably won't notice a difference unless your screwing around with
custom locales.

You might want to seek Dave's opinion before putting effort into a
patch.

   - Can I make parameters like en_language, en_territory,
 en_complete_name, et al class variables, and do away with any instance
 variables?

That data needs to be unique per locale object.

Cheers,

-J

--


pgpYSgrjkgzy4.pgp
Description: PGP signature


[rfc] DateTime::Format::DateParse

2005-07-23 Thread Joshua Hoblitt
Hi Folks,

I think my post about this simple module, as part of yet another thread about
why DT doesn't have a Date::Parse equivalent parser, was missed.  Anyways, I've
dumped some code into the DT CVS tree under modules/DateTime-Format-DateParse/.
It looks like SF's ViewCVS is lagging pretty far behind these days so you'll
have to actually checkout the module to look at it.

Comments?

Cheers,

-J

--
NAME
   DateTime::Format::DateParse - Parses Date::Parse compatible formats

SYNOPSIS
   use DateTime::Format::DateParse;

   my $dt = DateTime::Format::DateParse-parse_datetime( $date );
   my $dt = DateTime::Format::DateParse-parse_datetime( $date, $zone );
DESCRIPTION
   This module is a compatibility wrapper around Date::Parse.

USAGE
   Import Parameters

   This module accepts no arguments to it's import method and exports no
   symbols.

   Methods

   Class Methods

   * parse_datetime($date [, $zone])
   Accepts a Date::Parse compatible $date string and optionally a
   Time::Zone compatible $zone string.

   Returns a DateTime object.

GOTCHAS
   * If parse_datetime is called without $zone then the timezone of the
   returned DateTime object is set to the local timezone.  This is con-
   sistent with the behavior of Date::Parse.
   * If parse_datetime is called with a $zone that DateTime::TimeZone does
   not understand then the returned DateTime object will have it's time-
   zone set to a fixed offset from UTC.  This means that DST information
   is not available and date math will not reflect DST transitions. This
   may be resolved by using the DateTime::TimeZone::Alias module to
   alias the Time::Zone timezone to an Olson DB name.  This may be done
   automatically in a future release.

CREDITS
   Graham Barr (GBARR) [EMAIL PROTECTED], author of Date::Parse

   Everyone at the DateTime Asylum.

SUPPORT
   Support for this module is provided via the datetime@perl.org email
   list.  See http://lists.perl.org/ for more details.

AUTHOR
   Joshua Hoblitt (JHOBLITT) [EMAIL PROTECTED]

COPYRIGHT
   Copyright (c) 2005  Joshua Hoblitt. All rights reserved. This program
   is free software; you can redistribute it and/or modify it under the
   same terms as Perl itself.

   The full text of the licenses can be found in the LICENSE file included
   with this module, or in perlartistic and perlgpl as supplied with Perl
   5.8.1 and later.

SEE ALSO
   Date::Parse, Time::Zone, DateTime, DateTime::TimeZone, DateTime::Time-
   Zone::Alias, http://datetime.perl.org/


pgpQq9kIBMCgs.pgp
Description: PGP signature


Re: porting DateTime to Perl6

2005-07-23 Thread Joshua Hoblitt
On Fri, Jul 22, 2005 at 10:46:24PM -0300, Flavio S. Glock wrote:
 Dave has started DateTime, and I'm working on Pugs modules
 DateTime::Span, DateTime::SpanSet and a new module called
 DateTime::Recurrence, as well as the base modules Span, Recurrence,
 and Set-Infinite. Everything is under the /ext directory.

Dave has started down a path for something which is/will be engineered
very differently from the p5 version of DateTime.  I'm not saying this
is a bad thing, especially in the long run, I'm just trying to start a
discussion point on what the 'best' way to do things for the time being
is.  Hopefully sparking the interest of people (other then just Dave to
work on the p6 implementation (myself included).

 I'm splitting the modules into a functional implementation class and
 a OO api class.
 I found this separation useful when writing tests and optimizing. The
 functional base objects can be memoized if desired, and it allows to
 have multiple implementations under the same api.

That does seem reasonable.  Those modules don't have the complex
interdependencies that DateTime has with timezones, locales etc.  I
think it will be a large enough effort to get the DateTime -
DateTime::TimeZone interaction working under p6 without going through a
major design overhaul at the same time.  Then again, I do tend to be a
pessimist...

Cheers,

-J

--


pgpvXUuBcIYAr.pgp
Description: PGP signature


Re: DateTime.pm on a Diet

2005-07-22 Thread Joshua Hoblitt
On Thu, Jul 21, 2005 at 01:54:30PM +1000, Rick Measham wrote:
 I want to wrap this up and release so there's 24 hours to finalise the 
 name. Here's the names I like thus far:
 
 DateTime::LazyInit (from John Siracusa)
 DateTime::Mock (from Joshua Hoblitt)
 DateTime::Diet (original development name based on the subject)
 
 If anyone has any interest, please comment in the next 24 hours (based 
 on the timestamp of this message)

I'm not trying to beat this thread to death but it just occurred to me
that this is following the proxy design pattern.  So DateTime::Proxy
might be a good name as well.

Of the three name in your list I think I like DateTime::LazyInit more
than the others.

Cheers,

-J

--


pgpRyOZFJZvo4.pgp
Description: PGP signature


porting DateTime to Perl6

2005-07-22 Thread Joshua Hoblitt
Hi Folks,

It appears as if Pugs is very close to being able to host a major
framework like DateTime.  I think that it's 'time' to start considering
porting DateTime to Perl6.  Even if for no other reason then to help
debug Pugs.  The big question that I believe needs to be settled is do
we make a 'straight' port of DateTime to Perl6 or do we take the
opportunity to do some re-engineering?

My opinion: While there are several things in DateTime's
API/implementation that I'd like to see reworked I'm fearful of falling
prey to Second System Syndrome.  I also feel like DateTime hasn't been
around long enough to have felt out all the issue's that could/should be
addressed in an API change.  My proposal is that the initial port be a
straight across translation of DateTime to Perl6 and that serious
re-engineering work be put off for DateTime2.

Thoughts? Comments?

Cheers,

-J

--


pgp4m3xSphVUJ.pgp
Description: PGP signature


Re: Arbitrary Date Parsing [Was: Re: Date::Parse (Time::Local?) choking on years between 1956-1938 and wrong below, on FC4/5.8.6]

2005-07-21 Thread Joshua Hoblitt
On Fri, Jul 08, 2005 at 03:34:22PM -0500, Dave Rolsky wrote:
 On Fri, 8 Jul 2005, Rick Measham wrote:
 
 It's been discussed before, and the main reason is below. There's just no 
 way to properly parse a datetime. You can make 'best guesses'. But you 
 should probably use something else to make your guesses, then offer them 
 to the user to pick which they meant.
 
 DateTime prides itself on being accurate and predictable and should never 
 produce unexpected results.
 
 Eh, you're sort of putting words in my mouth here.
 
 I'd be happy to see Date::Parse style parsing as a DateTime::Format 
 module, with the understanding that it may get things wrong or be unable 
 to parse things at all.
 
 I think Graham has even mentioned something about it himself, though that 
 could be complete tish.
 
 It'd be super trivial to wrap Date::Parse in a DateTime::Format module.

Yep, it sure was.  I just checked it into CVS under
modules/DateTime-Format-DateParse.  I'll wait a few days for feedback
before kicking it to CPAN.

Cheers,

-J

--


pgp2odHXdWIhF.pgp
Description: PGP signature


Re: Date time Issue

2005-07-21 Thread Joshua Hoblitt
On Tue, Jul 19, 2005 at 10:44:17AM -0500, Anthony, Joseph wrote:
 The string date has a value as 'Jul 18, 2005 7:45:17 PM' and when I directly
 store it to an oracle database field datetime, it's storing as
 07/18/2005 07:45:17 AM. Not sure why it's converted to AM instead PM.

The issue is either a) Oracle's parser is not doing what you expect or
b) the database field your inserting into isn't configured to to display
your data properly.

If the problem is 'a' you need to 'filter' the format of your time
strings into something that Oracle can understand.  Rick has already
responded with a means of doing this. If the problem is because of 'b',
you'll need to search through the Oracle SQL reference for something
like NLS_TIMESTAMP_FORMAT.

Cheers,

-J

--


pgpTAOehjHTUf.pgp
Description: PGP signature


Re: DateTime::Sort::Key

2005-05-03 Thread Joshua Hoblitt
On Wed, Apr 27, 2005 at 10:39:08AM -0500, Dave Rolsky wrote:
 
 On a side note, I don't really like the namespace Sort::Key itself, since 
 it's not clear what that means.  I'd think something like Sort::Datatype 
 or Sort::Custom or something like that might be a little clearer.  This is 
 something that's probably best discussed on the module authors list 
 (module-authors@perl.org)

I dislike the namespace as well.  It sounds like this module basically
just sorts objects so I would expect to find both 'Sort' and 'Object' as
components of it's namespace...

-J

--


pgpiBQpBEWpwR.pgp
Description: PGP signature


Re: Proposal for a new, more rational calendar

2004-12-21 Thread Joshua Hoblitt
On Tue, 21 Dec 2004, Dave Rolsky wrote:
3.) Doesn't your innovation mean that, for some folks, the date changes
when the sun is overhead?
Yes ... but those folks live in the middle of the Pacific Ocean.
They don't care what day it is anyway!
Some (but not all) of us do care what day it is... :)
-J
--


DateTime::Duration 'in_units' does not properly normalize units

2004-12-13 Thread Joshua Hoblitt
Hi Tim,
It looks like the normalization is hosed.
Cut 'n Paste-able example:
--
use DateTime::Duration;
my $dur = DateTime::Duration-new( hours = 2.67 );
print hours: ,$dur-in_units( 'hours' ), \n;
print minutes: ,  $dur-in_units( 'minutes' ), \n;
print seconds: ,  $dur-in_units( 'seconds' ), \n;
print nanoseconds: ,  $dur-in_units( 'nanoseconds' ), \n;
--
-J
--
On Mon, 13 Dec 2004, Tim Jenness wrote:
perldl $dur = DateTime::Duration-new( hours = 2.67);
perldl print $dur-minutes
40.2
perldl print $dur-seconds
0
How can that be sane? So you ask for minutes and you get fractional
minutes but you ask for seconds and get zero?
 !
Hang on.
perldl print $dur-in_units( 'minutes' )
160.2
perldl print $dur-in_units( 'seconds' )
0
perldl
so clearly in_units() is doing the right thing except that for 'seconds'
it's not working at all
perldl print $dur-in_units( 'hours' )
2
and neither is hours since that should say 2.67 to be consistent with
minutes returning 160.2.
I'm extremely confused by this seeming inconsistency.
--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj



Re: DateTime::Duration 'in_units' does not properly normalize units

2004-12-13 Thread Joshua Hoblitt
On Mon, 13 Dec 2004, Dave Rolsky wrote:
On Mon, 13 Dec 2004, Joshua Hoblitt wrote:
It looks like the normalization is hosed.
This method, for the nth time, does not convert between units which do not 
have a fixed conversion rate.
Whooo, I seem to have missed the bus here.  Wasn't the entire point of
-in_units so people would stop bitching about the other accessors not doing
what they had been trained to expect?  How is -in_units possibly useful
otherwise?
I for one am getting really tired of all the complaints about DT::Duration.
Why don't we just add a bunch of accessors, with really verbose names, that
return deltas relative to -01-01T00:00:00 and document the hell out of the
fact that this is what's going on.  e.g.
--
-estimated_years
-guessed_months
-imperfect_days,
-imprecise_hours
-loose_minutes,
-rough_seconds
-surmised_nanoseconds
-uncertain_years
-unprecise_months
-unscientific_days
-approximate_hours
-relative_minutes
-seconds_relative_to_0
.
.
__
I'd also point out that it probably won't work well with non-integer units. 
I'm not sure what'll happen when you try to add 160.2 minutes to a DateTime 
object, but it won't be anything good, I'm sure.
snip/
How can that be sane? So you ask for minutes and you get fractional
minutes but you ask for seconds and get zero?
Cause really it should just blow up when you give it fractional anything.
The validation spec doesn't limit the input to integers.  Either the
implementation or the spec needs to be fixed...
--
my %p = validate( @_,
 { years   = { type = SCALAR, default = 0 },
   months  = { type = SCALAR, default = 0 },
   weeks   = { type = SCALAR, default = 0 },
   days= { type = SCALAR, default = 0 },
   hours   = { type = SCALAR, default = 0 },
   minutes = { type = SCALAR, default = 0 },
   seconds = { type = SCALAR, default = 0 },
   nanoseconds = { type = SCALAR, default = 0 },
   end_of_month = { type = SCALAR, default = undef,
 regex = 
qr/^(?:wrap|limit|preserve)$/ },
 } );
--
Cheers,
-J
--


Re: DateTime::Duration 'in_units' does not properly normalize units

2004-12-13 Thread Joshua Hoblitt
On Mon, 13 Dec 2004, Tim Jenness wrote:
On Mon, 13 Dec 2004, Dave Rolsky wrote:
Maybe it could be something like DT::Duration::Fractional?  What do others
think?
A variant of Duration that assumes standard lengths for day, minutes, hour
etc, and with a caveat that it will always add seconds when combined with
a DateTime object would be great.
If this is the route to be taken, it should be sufficient to create a 
standard
DateTime::Duration object (instead of a subclass) with the duration expressed
on as seconds/nanoseconds.  Then -in_units would work as you had expected.
Am I volunteering...?
Are you? :)
Cheers,
-J
--


missing CVS tags

2004-11-11 Thread Joshua Hoblitt
Were CVS tags intentionally omitted for the 0.22 and 0.23 releases of
DateTime.pm?
-J
--


[OT] Re: Activestate PPMs for DateTime?

2004-11-03 Thread Joshua Hoblitt
Who is the point of contact for AS on this issue?
-J
--
On Tue, 2 Nov 2004, Dave Rolsky wrote:
On Mon, 1 Nov 2004, Yitzchak Scott-Thoennes wrote:
Not that I'm blaming DateTime; there's plenty of blame to go around.
ActiveState is to blame for (as rumor has it) having someone maybe
sometime completely rewrite their build scripts, instead of just
quickly addressing this deficiency.  DateTime is to blame for using a
build method that doesn't yet have support from a sizable segment of
the potential user base.  Module::Build is to blame for not coming up
with a way to have dependencies honored by Makefile.PL-friendly tools;
indeed, for not listing itself a dependency at all.  And lastly and
most importantly, ExtUtils::MakeMaker is to blame for having such a
hokey mechanism for dependencies in the first place (to whit: run
Makefile.PL and parse out the PREREQ line from the generated
Makefile).  Oh, and lets not leave out CPAN::FirstTime; everything
might work out ok if it would have a default mirror option; see
http://ppm.activestate.com/BuildStatus/5.8-windows/windows-5.8/DateTime-Locale-0.09.txt
Clearly the easiest for AS is to simple install Module::Build and its 
dependencies before trying to build PPMs.

What's the way forward in all this?  I don't know.  I do know that
the Module::Build people are working on what I assume will be a separate
module to parse complex dependency information out of META.yml.  We'll
see how it goes, and if various tools will adopt it.  I don't hold my
breath.
You hold your breath on it getting written, or getting adopted?  It'll get 
written, I'm sure.  Whether people will adopt it is up to them.

-dave
/*===
VegGuide.Org
Your guide to all that's veg.
===*/



Activestate PPMs for DateTime?

2004-11-01 Thread Joshua Hoblitt
Has anyone that is a win32/activeperl user complained to Activestate that they
are not providing a DateTime PPM?  I assume that DateTime is still working on
win32 but the PPM status page shows that DT 0.22 is failing to build on _all_
platforms.
-J
--
-- Forwarded message --
Date: Sun, 31 Oct 2004 08:43:14 -0500
From: Ricardo SIGNES [EMAIL PROTECTED]
To: Joshua Hoblitt [EMAIL PROTECTED]
Subject: Re: Time::Human
* Joshua Hoblitt [EMAIL PROTECTED] [2004-10-30T22:08:31]
I'd like to see Time::Human become just a wrapper for
DateTime::Format::Human.
Would it be possible for you to submit patches against DT::F::Human instead?
That's not really acceptable for me.  I can't use DateTime at work
because it can't be automatically deployed via the ActiveState PPM
system.  I like DateTime, but until it's automatically installable, it
does me no good at work.
--
rjbs


Re: Activestate PPMs for DateTime?

2004-11-01 Thread Joshua Hoblitt
That is goofy... has anyone opened a trouble ticket on this or complained
directly?
-J
--
On Mon, 1 Nov 2004, Dave Rolsky wrote:
On Mon, 1 Nov 2004, Joshua Hoblitt wrote:
Has anyone that is a win32/activeperl user complained to Activestate that 
they are not providing a DateTime PPM?  I assume that DateTime is still 
working on win32 but the PPM status page shows that DT 0.22 is failing to 
build on _all_ platforms.
It's cause it needs Module::Build for some of the dependencies and their 
build boxes don't have Module::Build installed (which is goofy).

-dave
/*===
VegGuide.Org
Your guide to all that's veg.
===*/


[announce] DateTime::Format::ISO8601 0.0402

2004-10-29 Thread Joshua Hoblitt
Released to CPAN.
Changes since 0.0401
- add 8 missing formats, patch by Kelly McCauley
Cheers,
-J
--


Re: DateTime::Event::Sunrise altitude angle

2004-10-20 Thread Joshua Hoblitt
Hi Matt,

On Tue, 19 Oct 2004, Matt Sisk wrote:

 [EMAIL PROTECTED] wrote:
 
 Hi Joshua,
 
 I am not sure about this. I need to check with Paul to see if this is valid.
   
 
 
 Valid? Other than the patch he submitted appeared to not take into 
 account a decimal place, there's nothing invalid about the suggestion.

I probably should have tested that patch before submitting it. :)  You are
correct that it needs to allow a decimal place.

 The regular expression encompasses values that are generally agreed upon 
 to be civil/nautical/astronomical twighlight (i.e. dusk), plus when the 
 lower disk of the sun touches horizon at sea level, middle of the sun, 
 etc. Same for dawn. Other than these socially based standards, the same 
 equations work perfectly well for arbitrary angles of elevation.

Correct again. :)

-J

--


[announce] DateTime::Format::Human

2004-10-16 Thread Joshua Hoblitt
Released to CPAN.

This is a port of Time::Human to the DateTime::Format API.

Cheers,

-J

--


Re: DateTime::Format::Strptime speed compared to Time::Piece

2004-09-09 Thread Joshua Hoblitt
Hi Robin,

You can more then double your performance with DateTime::Format::Strptime by
instantiating a parser object and reusing it.  You should also keep in mind
that Time::Piece doesn't really support leapseconds (it may be able to parse
them on some platforms if it's using gmtime(3)...  haven't looked at the
source).

--
use Time::Piece;
use Benchmark qw( cmpthese );
use DateTime::Format::Strptime qw( strptime );

my $dtstrp = DateTime::Format::Strptime-new( pattern = %Y-%m-%dT%H%M%S);

cmpthese ( -3,
{
'DT Strptime' = sub {
$dtstrp-parse_datetime(2004-10-10T101010);
},
'DT Strptime imported' = sub {
strptime(%Y-%m-%dT%H%M%S, 2004-10-10T101010);
},
'Time::Piece' = sub {
Time::Piece-strptime(2004-10-10T101010, %Y-%m-%dT%H%M%S);
},
}

);
--

Rate DT Strptime imported DT StrptimeTime::Piece
DT Strptime imported  1338/s   ---54%   -98%
DT Strptime   2916/s 118%  --   -97%
Time::Piece  85687/s6305%   2839% --

Cheers,

-J

--

On Thu, 9 Sep 2004, Robin Phillips wrote:

 Hi,
 
 I have been converting a couple of programs that were using Time::Piece as 
 their date/time handling module, to use DateTime.pm instead. 
 
 However it seems that DateTime.pm apears to be about 700 times slower 
 than Time::Piece when parsing dates.
 
 The little program below takes 15 seconds to do 10,000 calls to the new 
 strptime and only 2 seconds to do 100,000 (ie 10x more) calls to the old 
 version (on my machine).
 
 Is this something to do with Time::Piece using a C library and DateTime 
 doing things in perl instead? Or is there some otherway of doing this date 
 parsing using DateTime that is faster?
 
 Robin
 
 -
 #!/usr/bin/perl -w
 use strict;
 use DateTime ;
 use DateTime::Format::Strptime qw{strptime};
 use Time::Piece;
 
 print gmtime-datetime, \n;
 for (my $i =0; $i =10_000; $i++) {
   my $file_datetime = strptime(%Y-%m-%dT%H%M%S, 2004-10-10T101010);
 }
 
 print gmtime-datetime, \n;
 
 for (my $i =0; $i =100_000; $i++) {
   my $file_datetime = Time::Piece - strptime(2004-10-10T101010, 
 %Y-%m-%dT%H%M%S);
 }
 
 print gmtime-datetime, \n;
 
 exit;
 
 
 
 
 


Re: Formatters and DateTime subclasses

2004-09-07 Thread Joshua Hoblitt
On Sat, 4 Sep 2004, Dave Rolsky wrote:

 On Fri, 3 Sep 2004, Joshua Hoblitt wrote:
 
  Except for all those non-inheritable lexical variables in the DateTime namespace...
 
 Like what, the validation specs?

Ya.  Those are the lexicals that completely wreck inheritance.  Instead of
fixing this by making them all package varibles maybe it would make sense to
merge them all into a single package level hash.  That wouldn't be the cleanest
solution in the world but atleast it would minimize the namespace pollution.

-J

--


Re: Formatters and DateTime subclasses

2004-09-03 Thread Joshua Hoblitt
On Thu, 2 Sep 2004, Dave Rolsky wrote:

 Well, the original question was in regards to subclasses of DateTime.pm.
 Given that a subclass will inherit from_object(), that seems good enough.
 
  my $my_dt = My::DT::Subclass-from_object( object = DateTime-new );
 
 That should work without any changes to existing code.

Except for all those non-inheritable lexical variables in the DateTime namespace...

-J

--


Re: DateTime::LeapSecond is incorrect

2004-07-20 Thread Joshua Hoblitt
On Tue, 20 Jul 2004, Eugene van der Pijll wrote:

 Yes, but the difference on 1971-12-31 is undefined. For our utc time zone,
 we could define utc-TAI = 9s on 1971-12-31. Why we would want do do that,
 I don't know. But we could.

Leap-seconds are officially declared by the IERS but whatever.  The current 
implementation makes the delta effectively 9s on 1972-01-01, which is *wrong*.

 That's the one I meant. I don't think there's much user code out there that
 even cares about leap seconds.

Everyones code cares about leap-seconds depending on how you look at it.  Imagine 
someone writing an epoch timestamp, upgrading DateTime, and reading in the old 
timestamp.  There is now a 1 second error - Ouch.  The same thing applies for someone 
with a broken version of DateTime reading in a timestamp that was generated with a 
fixed version.  Or what about the people parsing stamps not generated by DateTime?

Cheers,

-J

--


Re: DateTime::LeapSecond is incorrect

2004-07-19 Thread Joshua Hoblitt
On Mon, 19 Jul 2004, Eugene van der Pijll wrote:

 UTC was not defined before 1972-01-01. In DateTime, utc is used as time
 zone before 1972. The behaviour of our utc before 1972 is undefined, and
 it's perfectly possible to have a leap second 1971-12-31T23:59:60.

Except that UTC is *defined* as being UTC-TAI = 10s on 1972-01-01.

 The earlier time standard, UT, had a non-integer difference with TAI. It was
 synchronised with the rotation of the earth regularly with the introduction
 of fractional leap seconds. The difference between UT and UTC on 1971-12-31
 was about 0.2 seconds, IIRC, so if our utc is equal to UT before 1972, it
 would be better to have no leap second in Dec 1971.

UT1-UTC was -.0474900 on that date but regardless IERS did not declare a leap-second 
so our implementation is incorrect any way you look at it.

  A possible patch to correct this is attached.  Are there any objections to
  this being committed?  This could potentially break existing code but only
  because the current behavior is broken.
 
 This would probably have some effect on my DT::Format::TAI module, as I had
 to correct for the extra second there. (But I can't check that at the
 moment.) Still, I'm in favour of this correction.

You mean DateTime::Format::Epoch::TAI64 or is there another module not on CPAN?  
Anyways, hopefully that's the only DateTime::* module that will have any breakage... I 
was more worried about end user code.

Cheers,

-J


Should TAI be DT::Format or DT::Calendar ?

2004-07-18 Thread Joshua Hoblitt
Hi Folks,

I'm having an itch to convert UTC-TAI.  I started off writing this a 
DateTime::Format module because the conversion is so simple but since TAI isn't just a 
display formating of the Gregorian/UTC system (different epoch, no leapseconds, etc.) 
I'm now thinking this should be DateTime::Calendar module.

Does anyone have an opinion on this?

-J

--


DateTime::LeapSecond is incorrect

2004-07-18 Thread Joshua Hoblitt
Hi Folks,

DateTime::LeapSecond claims that there have been 23 leap-seconds since the start of 
UTC.  This is _incorrect_.  There have been only 22 leap-seconds in the history of 
UTC.  This error is introduced on be the addition of a leap-second on 1972-01-01.  
That is the date when the delta been UTC-TAI is defined to be exactly +10 but no 
leap-second occurred.

A possible patch to correct this is attached.  Are there any objections to this being 
committed?  This could potentially break existing code but only because the current 
behavior is broken.

Cheers,

-J

--? DateTime.bs
? DateTime.c
? Makefile
? blib
? dt_leapsecond.diff
? leap_seconds.h
? pm_to_blib
? t/zz_00load.t
? t/zz_01sanity.t
? t/zz_02last_day.t
? t/zz_03components.t
? t/zz_04epoch.t
? t/zz_05set.t
? t/zz_06add.t
? t/zz_07compare.t
? t/zz_09greg.t
? t/zz_10subtract.t
? t/zz_11duration.t
? t/zz_12week.t
? t/zz_13strftime.t
? t/zz_14locale.t
? t/zz_15jd.t
? t/zz_16truncate.t
? t/zz_17set_return.t
? t/zz_18today.t
? t/zz_19leap_second.t
? t/zz_20infinite.t
? t/zz_21bad_params.t
? t/zz_22from_doy.t
? t/zz_23storable.t
? t/zz_24from_object.t
? t/zz_25add_subtract.t
? t/zz_27delta.t
? t/zz_28dow.t
? t/zz_29overload.t
? t/zz_30future_tz.t
Index: leaptab.txt
===
RCS file: /cvsroot/perl-date-time/modules/DateTime.pm/leaptab.txt,v
retrieving revision 1.1
diff -u -r1.1 leaptab.txt
--- leaptab.txt 6 Aug 2003 14:09:26 -   1.1
+++ leaptab.txt 19 Jul 2004 02:23:33 -
@@ -1,4 +1,3 @@
-1972  Jan. 1  +1
 1972  Jul. 1  +1
 1973  Jan. 1  +1
 1974  Jan. 1  +1
Index: lib/DateTime/LeapSecond.pm
===
RCS file: /cvsroot/perl-date-time/modules/DateTime.pm/lib/DateTime/LeapSecond.pm,v
retrieving revision 1.7
diff -u -r1.7 LeapSecond.pm
--- lib/DateTime/LeapSecond.pm  2 Dec 2003 05:09:48 -   1.7
+++ lib/DateTime/LeapSecond.pm  19 Jul 2004 02:23:33 -
@@ -83,7 +83,6 @@
 # year month day number-of-leapseconds
 #
 _init ( qw(
-1972  Jan. 1  +1 
 1972  Jul. 1  +1
 1973  Jan. 1  +1
 1974  Jan. 1  +1
@@ -143,7 +142,7 @@
 =item * leap_seconds( $rd )
 
 Returns the number of accumulated leap seconds for a given day,
-in the range 0 .. 23.
+in the range 0 .. 22.
 
 =item * extra_seconds( $rd )
 
Index: t/19leap_second.t
===
RCS file: /cvsroot/perl-date-time/modules/DateTime.pm/t/19leap_second.t,v
retrieving revision 1.21
diff -u -r1.21 19leap_second.t
--- t/19leap_second.t   10 Feb 2004 15:57:50 -  1.21
+++ t/19leap_second.t   19 Jul 2004 02:23:33 -
@@ -9,35 +9,35 @@
 
 # tests using UTC times
 {
-# 1971-12-31T23:58:20 UTC
-my $t = DateTime-new( year = 1971, month = 12, day = 31,
+# 1972-06-30T23:58:20 UTC
+my $t = DateTime-new( year = 1972, month = 6, day = 30,
hour = 23, minute = 58, second = 20,
time_zone = 'UTC',
  );
 my $t1 = $t-clone;
 
-# 1971-12-31T23:59:20 UTC
+# 1972-06-30T23:59:20 UTC
 $t-add( seconds = 60 );
-is( $t-year, 1971, year is 1971 );
+is( $t-year, 1972, year is 1972 );
 is( $t-minute, 59, minute is 59 );
 is( $t-second, 20, second is 20 );
 
-# 1972-01-01T00:00:19 UTC
+# 1972-07-01T00:00:19 UTC
 $t-add( seconds = 60 );
 is( $t-year, 1972, year is 1972 );
 is( $t-minute, 0, minute is 0 );
 is( $t-second, 19, second is 19 );
 
-# 1971-12-31T23:59:60 UTC
+# 1972-06-30T23:59:60 UTC
 $t-subtract( seconds = 20 );
-is( $t-year, 1971, year is 1971 );
+is( $t-year, 1972, year is 1972 );
 is( $t-minute, 59, minute is 59 );
 is( $t-second, 60, second is 60 );
 is( $t-{utc_rd_secs} , 86400, utc_rd_secs is 86400 );
 
 
 # subtract_datetime
-my $t2 = DateTime-new( year = 1972, month = 1, day = 1,
+my $t2 = DateTime-new( year = 1972, month = 07, day = 1,
 hour = 0, minute = 0, second = 20,
 time_zone = 'UTC',
   );
@@ -83,24 +83,24 @@
 # tests using time zones
 # leap seconds occur during _UTC_ midnight
 
-# 1971-12-31 20:58:20 -03:00 = 1971-12-31 23:58:20 UTC
-my $t = DateTime-new( year = 1971, month = 12, day = 31,
+# 1972-06-30 20:58:20 -03:00 = 1972-06-30 23:58:20 UTC
+my $t = DateTime-new( year = 1972, month = 6, day = 30,
hour = 20, minute = 58, second = 20,
time_zone = 'America/Sao_Paulo',
  );
 
 $t-add( seconds = 60 );
-is( $t-datetime, '1971-12-31T20:59:20', normal add );
+is( $t-datetime, '1972-06-30T20:59:20', normal add );
 is( $t-minute, 59, min );
 is( $t-second, 20, sec );
 
 $t-add( seconds = 60 );
-is( $t-datetime, '1971-12-31T21:00:19', add over a leap second );
+is( $t-datetime, '1972-06-30T21:00:19', add 

Re: Moving to subversion?

2004-06-05 Thread Joshua Hoblitt
Hi Dave,

Are you going to go ahead with the conversion?  I'm eager to switch to SVK.

Cheers,

-J

--

On Wed, 21 Apr 2004, Dave Rolsky wrote:

 I'm getting fed up with the damn sourceforge CVS instability and slowness.
 
 What do people think of moving to Subversion, hosted either on my own box
 (svn.urth.org) or maybe svn.perl.org if I can talk Ask and/or Robert into
 it?
 
 I'd convert the existing CVS repo, and since we don't have any branches
 (AFAIK), it should work fine (tags convert ok, IIRC).
 
 Subversion runs on Windows (and there's a binary installer), Linux, BSDs,
 Solaris, and Mac OS X.
 
 Objections?  Comments?
 
 
 -dave
 
 /*===
 House Absolute Consulting
 www.houseabsolute.com
 ===*/
 


Re: Moving to subversion?

2004-04-21 Thread Joshua Hoblitt
On Wed, 21 Apr 2004, Dave Rolsky wrote:

 I'm getting fed up with the damn sourceforge CVS instability and slowness.

But at least it's backed up occasionaly...

 What do people think of moving to Subversion, hosted either on my own box
 (svn.urth.org) or maybe svn.perl.org if I can talk Ask and/or Robert into
 it?

I'd say svn.perl.org would be my first choice (as long as one is doing backups).  I'm 
also willing to host the SVN tree.

-J

--


Re: DateTime API gets a ++

2004-04-04 Thread Joshua Hoblitt
It seems we've actually had a fair amount of coverage on Perlmonks.

http://www.perlmonks.org/index.pl?node=+DateTimego_button=Search

-J

--

On Sun, 4 Apr 2004, Dave Rolsky wrote:

 On Sun, 28 Mar 2004, Rick Measham wrote:

  I don't know who he is, but DateTime is the only module mentioned in
  this thread on perlmonks with high praise:
 
  http://www.perlmonks.org/index.pl?node_id=339217
 
  Though people might be interested:
   ... My favourite example of a module that gets this pretty-much
  right, IMO, is DateTime, which I can almost use in my sleep. ... 

 I was very happy to see this comment on PM.  Thanks to everyone who's
 contributed to this list, since all the feedback I've gotten from various
 folks has been quite valuable in creating the API.


 -dave

 /*===
 House Absolute Consulting
 www.houseabsolute.com
 ===*/



Re: ANNOUNCE: DateTime 0.21

2004-03-29 Thread Joshua Hoblitt
On Mon, 29 Mar 2004, Dave Rolsky wrote:

 On Sun, 28 Mar 2004, Eugene van der Pijll wrote:

  Is it possible to detect mixed durations other than checking all of
  is_positive, is_zero and is_negative? For example by adding an is_mixed
  method?

 Something like that, with a better name than is_mixed would be good.
 Name suggestions, anyone

How about adopting some mathematical terminology.  Like, 'is_real' or 'is_complex'?

-J

--


Re: New module Date::Object - An alternative to DateTime, but not a replacement.

2004-03-21 Thread Joshua Hoblitt
Hi Graciliano,

On Sun, 21 Mar 2004, Graciliano M. P. wrote:

 I have just released the module Date::Object, that in the first view is an
 alternative to DateTime, at least for the most common things when handling
 dates.

It nice to see that the DateTime project has become so well known. :)

 http://search.cpan.org/~gmpassos/Date-Object-0.01/

 The main pourpose is to handle dates using a single object or make multiple
 Date::Objects work together to calculate and handle dates.

 Other main poupose of Date::Object is to find a simple way to store dates in
 a persistent enverioment (any database) using a simple INTEGER field.

Did you see CDateTime::epoch and CDateTime::from_epoch in the DateTime.pm pod?

 The use of a INTEGER field for that make possible searches in the DB by
 ranges, what is impossible with normal storages of dates, specially if they
 are saved as STRING, generally in the comon format of -MM-DD. Also an
 INTEGER field have all the informations of a date, including year, month,
 day, hour, minute, second and timezone. Other good thing is that any DB
 supports INTEGER fields, what doesn't make our Perl code dependent of the
 SQL nuances of each different way to handle dates of each DB.

I don't know of any 'SQL' database that can't search on time ranges.  Although, it is 
true that these functions are generally extensions to ANSI SQL.

 Internally Date::Object has a simple architecture and is small compared to
 other Date modules, since all is based in the time() (all the seconds from
 1970-1-1) of the object. Soo, each object has it's own time value and
 timezone, and from this 2 values any information is calculated. Soo, change
 only 2 values make all the work easier to create the module and move the
 date through the timeline, and with simple methods is possible to add/remove
 days, weeks, months, years, and make comparations.

That first statement is incorrect.  The behavior of Ctime is platform specific.  In 
your database example above, you'd have to make sure all the platforms accessing the 
database use the same epoch.  For a solution to this problem please see 
DateTime::Format::Epoch.

The timezone handling is completely broken.  Despite the fact Cisdst is in the API 
only offsets from GMT are supported.  This means there is _NO_ way to tell if changing 
timezones also causes a DST change

UTC is not supported but in fairness support for it isn't claimed.

The data math is also broken in many ways.  The algorithm for calculating leap years 
(year / 4) is incorrect.  A lot of mutators show very primitive behavior.  If I add 1 
month to January 31st what is the date?

I've just skimmed through the code so I'm sure I missed errors.  Getting date and time 
handling _correct_ is really, really, really hard.  (Insert the standard plug for Dave 
Rolsky's DateTime.pm here)

 As any other author that releases a new module, I'm asking for some feedback
 about the module.

I'm sorry if this sound harsh but you've created another typical CDate::* module.  
There is a reason why getting DateTime and the related modules _correct_ took (and is 
taking) so much labor.  I don't think many people are cognizant of the complexity that 
lurks behind seemly simple issues in this domain.

I encourage you and anyone else that are considering writing a date and/or time 
handling module to discuss it on the [EMAIL PROTECTED] mailing list.

Cheers,

-J

--


[announce] DateTime::Calendar::Mayan 0.0601

2004-03-18 Thread Joshua Hoblitt
Released to CPAN.

Available immediately from:

http://kolea.ifa.hawaii.edu/~jhoblitt/pm/DateTime-Calendar-Mayan-0.0601.tar.gz

0.0601 Wed Mar 17 21:56:08 HST 2004
- fix test failures

Cheers,

-J

--




Bundle::DateTime prereqs

2004-03-17 Thread Joshua Hoblitt
Does it make sense to add Module::Build to the bundle?  DateTime::Locale immediately 
asks for it.

-J

--


date time handling in Parrot

2004-03-03 Thread Joshua Hoblitt
There are two threads running on the p6i list right now dealing with date and time 
handling.  The threads are Dates and Times and Epoch  Larry Wall has stated 
that by default Perl 6 will return time as a floating point number of seconds since 
2000.  Regardless of what Perl 6 does, I'm advocating that Parrot returns TAI.  If 
anyone has something constructive to say please hop in.

-J

--


Re: Chinese/Japanese calendars - GMP is a pre-requisite

2004-01-19 Thread Joshua Hoblitt
On Sat, 17 Jan 2004, David Wheeler wrote:

 On Jan 16, 2004, at 7:55 PM, Joshua Hoblitt wrote:

  I would do it the way we did it in DBD::Pg: Put it in t/lib:
 
  Why not use Module::Install?

 Because not everyone is connected to a network with access to a CPAN
 mirror. And those people will hate you.

RTFM on Module::Install

-J

--


Re: Perl 5.8.[23] + DateTime::Format::ISO8601 - leap year failure in t/02_examples.t (test code, not main code)

2004-01-19 Thread Joshua Hoblitt
On Sun, 18 Jan 2004, Jonathan Leffler wrote:

 When I try to build DateTime::Format::ISO8601 v0.04, I'm getting a
 test failure in t/02_examples.t:

 t/02_examples.NOK 24# Failed test (t/02_examples.t at line
 156)
 #  got: '2004-04-11'
 # expected: '2004-04-12'
 t/02_examples.ok 140/140# Looks like you failed 1 tests of
 140.
 t/02_examples.dubious

  Test returned status 1 (wstat 256, 0x100)
 DIED. FAILED test 24
  Failed 1/140 tests, 99.29% okay

 I think this is a leap year problem in the test.  The test is:

I've reproduced the bug and agree with your analysis.  I'll get a fixed release out 
soon.

Thanks for reporting this.

-J

--


Re: Chinese/Japanese calendars - GMP is a pre-requisite

2004-01-16 Thread Joshua Hoblitt
On Fri, 16 Jan 2004, David Wheeler wrote:

 I would do it the way we did it in DBD::Pg: Put it in t/lib:

Why not use Module::Install?

-J

--


Re: ANNOUNCE: DateTime::Fiction::JRRTolkien::Shire 0.02

2003-12-08 Thread Joshua Hoblitt
On Mon, 8 Dec 2003, Mathieu Arnold wrote:

 Shouldn't this be a DateTime::Calendar:: thing ?

http://datetime.perl.org/developer/namespace.html

-J

--


Re: DateTime::TimeZone::Lite and DateTime::TimeZone::Olson::XS

2003-11-17 Thread Joshua Hoblitt
 You would still have to create the timezone singletons -- unless you're
 suggesting that these would be destroyed when not in use, you would
 still end up running into the same memory issues once enough timezone
 objects have been created.

And you wouldn't be able to take advantage of page sharing.

-J

--


Re: DateTime::TimeZone::Lite and DateTime::TimeZone::Olson::XS

2003-11-17 Thread Joshua Hoblitt
 Is this ALL each timezone provides, and nothing else? Does anything directly
 access timezone object structures in any other way? Because if not, it
 should be pretty easy to create an XS wrapper to implement only these
 functions, even say by accessing the POSIX zoneinfo database given a
 timezone name?

How many win32 (and non-POSIX systems) have the zoneinfo database?

-J

--


[announce] DateTime::Format::ISO8601 0.04

2003-11-15 Thread Joshua Hoblitt
Released to CPAN.

Available immediately from:

http://kolea.ifa.hawaii.edu/~jhoblitt/pm/DateTime-Format-ISO8601-0.04.tar.gz

Changes since 0.03

- require DT 0.18 and DT::F::B 0.77
- recommend Test::Pod 0.95 and File::Find::Rule 0.24
- doc update
- test update
- fix bug in -YY spec
- default handling of 2-digit years is now 0-49 as 20xx and 50-99 as 19xx
- add DefaultCutOffYear()
- add DefaultLegacyYear()
- add base_datetime()
- add clone()
- add cut_off_year()
- add legacy_year()
- add new()
- add set_base_datetime()
- add set_cut_off_year()
- add set_legacy_year()

Cheers,

-J

--




DateTime::Format::DateManip test failures

2003-11-15 Thread Joshua Hoblitt
I've been seeing this build error for a couple of months now on at least half a dozen 
different systems.

-J

--
/usr/bin/perl Build test
t/00load...ok
t/01conversionsNOK 3# Failed test (t/01conversions.t at line 69)
#  got: '2003032300:00:00'
# expected: '2003032303:00:00'
t/01conversionsNOK 4# Failed test (t/01conversions.t at line 69)
#  got: '2003032312:00:00'
# expected: '2003032315:00:00'
t/01conversionsok 6/6# Looks like you failed 2 tests of 6.
t/01conversionsdubious
Test returned status 2 (wstat 512, 0x200)
DIED. FAILED tests 3-4
Failed 2/6 tests, 66.67% okay
Failed Test   Stat Wstat Total Fail  Failed  List of Failed
---
t/01conversions.t2   512 62  33.33%  3-4
Failed 1/2 test scripts, 50.00% okay. 2/7 subtests failed, 71.43% okay.



Re: [Fwd: DateTime::Duration comparisions]

2003-11-14 Thread Joshua Hoblitt
On Fri, 14 Nov 2003, Dave Rolsky wrote:

 I don't mind the idea of adding a compare() class method that accepts a
 base datetime and uses DateTime-now, per Rick's suggestion.

I proposed something just short of this *months* ago and nobody even responded to my 
RFC.

DT::Q could be either used by this 'compare' class or be extended to include 
comparison operators.  Two DT::Q objects could be compared deterministically.

-J

--
 From [EMAIL PROTECTED] Fri Nov 14 17:40:01 2003
 Date: Sun, 17 Aug 2003 16:02:09 -1000 (HST)
 From: Joshua Hoblitt [EMAIL PROTECTED]
 To: DateTime [EMAIL PROTECTED]
 Subject: [RFC] DateTime::Quantitative was Re: Subtraction Broken?

 I'm not too sure about the name.  I wanted to make sure it couldn't be confused with 
 DateTime::Duration and still be meaningful.

 Is this the best approach?  I can't see this type of functionality being cleanly 
 implemented in DT::Duration.

 -J

 --
 DateTime::Quantitative - returns duration values normalized to a fixed point in time

 -new( datetime = $dt, duration = $dtd )

 Like DT::Duration it would provide:

 -years;
 -months;
 -weeks;
 -days;
 -hours;
 -minutes;
 -seconds;
 -nanoseconds;
 -sign;
 -is_positive
 -is_zero
 -is_negative

 In addition:

 -clone

 -datetime
 -duration

 returns the component object

 If DT::Q is mutable (might not be a good idea) it would also include:

 -set_datetime( object = $dt )
 -set_duration( object = $dtd )

 updates the component object

 No math operators would be overloaded but perhaps stringification would be allowed.



Re: DateTime::TimeZone issues...

2003-11-13 Thread Joshua Hoblitt
 Seriously, I'd like to eventually speed up/slim down the time zone stuff
 but just getting it working took an enormous amount of development effort.
 Making a super-fast whiz-bang version that still works is not trivial.

Maybe we should ask around to try and determine the level of interest in using 
DT::TZ::* under mod_perl.  If it's high we can apply for a linuxfund or TPF grant to 
fund Dave.  Of course those that have a _financial_ interest in this can fund Dave 
directly...

-J

--


Re: DateTime::TimeZone issues...

2003-11-13 Thread Joshua Hoblitt
I don't think the memory usage of DT::TZ is really that excessive.  It's been over 3 
years since I've had a sever with less then 1GB of ram in it.  That's easily enough 
memory for 64 x 12.5MB apache children that aren't doing page sharing.

-J

--


Re: parse_datetime and format_datetime

2003-11-05 Thread Joshua Hoblitt
 Just out of curiousity...why the '_datetime' suffix on these methods?
 Isn't that redundant? Or was it assuming that these methods might be
 showing up in classes outside of the DateTime namespace?

To differentiate from: _date, _time, _span, etc.

 And speaking of brevity...the 0.18 docs for DateTime say that
 'time_zone_long_name' is short for $dt-tz-name. I see no evidence of a
 'tz' method, though it'd be nice to have around, along with 'tz_name', etc.

'tz' is a key in the blessed hash of a DateTime object.  The docs should say 
$dt-time_zone-name.

-J

--


Re: DT::Incomplete more methods

2003-11-04 Thread Joshua Hoblitt
On Tue, 4 Nov 2003, Flavio S. Glock wrote:

 Joshua Hoblitt wrote:
 
 $span = $dti-span;
 
  I really like the idea of being able to measure
  the uncertainty in an object.  What if the year
  and day are known but not the month?  Would a
  span set be returned?

 spanset would be a separate method. Here is an example:

Looks good.

-J

--


Re: DT::Incomplete more methods

2003-11-03 Thread Joshua Hoblitt
   $span = $dti-span;

I really like the idea of being able to measure the uncertainty in an object.  What if 
the year and day are known but not the month?  Would a span set be returned?

-J

--


Re: [RFC] Astro related modules

2003-10-23 Thread Joshua Hoblitt
 I've now re-organized the astronomical calculation portions of the
 chinese calendar modules into the following. This should be nicer to the
 namespace. Please let me know if they look ok:

http://www.wafu.ne.jp/~daisuke/DateTime-Util-Calc-0.01.tar.gz
http://www.wafu.ne.jp/~daisuke/DateTime-Util-Astro-0.01.tar.gz
http://www.wafu.ne.jp/~daisuke/DateTime-Event-Lunar-0.01.tar.gz

 I also plan to create Astro::Event::SolarTerm, which will allow me to
 partition things nicely within my planned DT::C::Chinese and
 DT::C::Japanese.

Is Astro::Event::SolarTerm useful outside of the DateTime context?

-J

--


Re: Chinese Calendar Question (fwd)

2003-10-21 Thread Joshua Hoblitt
On Tue, 21 Oct 2003, Daisuke Maki wrote:

1) the Astro stuff. Just where to put it??

 So I know Joshua Hobblit has suggested

Astro::Calendrical::*

 It kind of seemed like (because these functions are specifically to
 calculate dates) it belongs more to DateTime::* namespace. Is there a
 possibility to create a namespace for such helper modules, which are
 not directly related to datetime calculations?

Absolutely.  I've suggested DateTime::Util for helpers before.  Astro::* makes sense 
for 'generic' astronomical calculations.  DateTime specific stuff should inhabit 
another namespace.

-J

--


Re: [Ann] DateTime::TimeZone::LMT 1.00

2003-10-19 Thread Joshua Hoblitt
 There's one problem with this modules.  DT.pm relies on the time zone
 object returning a value from the name() method, that when fead to
 DT::TZ-new, will recreate the original object.  This is used in DT.pm's
 Storable hooks in order to avoid saving the whole time zone object.  Right
 now, if someone were to freeze and thaw a DT object which used an LMT time
 zone, it would probably throw an error when they tried to thaw it.

 One possible fix is to have name() return undef for your object, and then
 DT.pm can explicitly check for this, and save the whole object.

 The downside to this is that it would mandate that all time zone
 implementations outside the DT::TZ core return undef for name().

 Other suggestions are welcome.

We could require that all 'external' time zome implementations have storable hooks of 
their own.  Then STORABLE_freeze() in DT could check for the hook and call it 
directly.   The downside is it will bloat the size of serialized DT objects as we'll 
have to store the class name of the TZ object.

-J

--


Re: [RFC] Astro:: modules

2003-10-18 Thread Joshua Hoblitt
 Anyway, here's what I got so far with the Astro:: stuff:

   Astro::Sun- stuff related to solar position
   Astro::Moon   - stuff related to lunar position
   Astro::Common - common calculation utilities

How common is Common?  Remember there is stuff like Astro::FITS::CFITSIO (also a 
good example of why C interfaces suck in perl) under that namespace.

   Astro::Earth::Location  - simple structure
 to store latitude/longitude, etc.

Do you know how accurate the algorithm is?  Our local guru has a 308 term polynomial. 
:)

   Astro::BigFloat - Wrapper to Math::BigFloat to allow
 toggling on/off the use of Math::BigFloat

Again, I'm concerned about namespace pollution.

 I by no means declare that these are good names: I used them just so I
 could roughly divide things up. Please suggest any ideas you might have.

 Here are some points that I'm kind of pondering about:
   - naming.
   - better organization

If all the algorithms are out of the CC book would about something like 
Astro::Calendrical::* ?

   - usage? is a plain procedural interface ok?

My personal preference is class methods over exporting stuff.

   use Astro::Sun qw(solar_longitude);
   my $degrees = solar_longitude($dt);

my $degrees = Astro::Sun-solar_longitude( $dt );

I think it makes the code more readable but obviously opinions are varied on this.

   - I think Astro::Common can be separated out into smaller packages.
   - when structure is settled, optimize a bit.

 Once I get the idea of how to organize these modules, I will polish them
 up, and bring them up again...


-J

--


Re: [Kinda OT] Could somebody double check this?

2003-10-17 Thread Joshua Hoblitt
 How about to refactor DateTime RD code into another
 module? There is already enough use for rd, minutes
 and seconds in other calendars to justify having a
 base module.

I think we've been over this before haven't we?  I thought the consensus was that a 
base class would be a good idea but that DateTime.pm should be left intact.  It makes 
more sense for a base class to 'grow up' independent of DT and if it makes sense (it's 
mature, minimal performance hit for using it, etc) DT can then be refactored to use it.

-J

--


Re: More flexibly subtract/difference methods

2003-10-11 Thread Joshua Hoblitt
  However, if DT::Duration is given 'year' units, it should not
  automatically convert it to months, because I may want to use that
  information in a non-gregorian context.

 Well, you might, but you can't ;)

I agree completely.

 Seriously, I think this idea that DateTime::Duration should work for other
 calendars is bogus, and I've said so before.

Dave++

 There's simply too many possible ways for this to break, and while it
 would be somewhat flexible, it wouldn't be flexible enough to work with
 many odd calendars (like Discordian, Aztec, etc.).

Dave++

  That is, if you move the year/month semantics to the calendar class,
  then DT::Duration can support (almost) any calendar.

 No, it can only support some fraction of calendars, those that are lunar,
 solar, or lunisolar.

Dave++

DateTime::Duration should focus the Gregorian calendar.  There is no possible way to 
make it sufficiently generic to support all possible calendars without giving up 
functionality useful in it's intended context.  The best we should do to support 
alternate calendars is to implement a method that returns an absolute time interval in 
calendar independent units.

There will have to be some fudging here.  For example, how many days should 3 months 
convert to?
--
my $dtd = DateTime::Duration-new( months = 3 );
my( $rd_days, $rd_secs, $rd_nanos ) = $dtd-rd_values;
# or for some interesting compatability...
my( $rd_days, $rd_secs, $rd_nanos ) = $dtd-utc_rd_values;
--
is $rd_days 93, 90, 87, or 84?  I'd vote for 93...

For reference, this is how I handled DT::Durations in DT::C::Mayan:

--
sub add_duration {
my( $self, $duration ) = @_;

my $dt = DateTime-from_object( object = $self );
$dt-add_duration( $duration );

my $new_self = $self-from_object( object = $dt );

# if there is an alternate epoch defined don't touch it
$self-{ rd }   = $new_self-{ rd };
$self-{ rd_secs }  = $new_self-{ rd_secs };

return( $self );
}
--

-J

--


Re: RE: figuring out the number of sundays in a given year

2003-09-21 Thread Joshua Hoblitt
 First: How many of a particular DOW are in a
 period. This is just a matter of dividing the
 total days by seven then adding one if
 needed. If a function were added for this,
 then I imagine its more a part of
 DateTime::Span rather than DateTime itself.

I already said this. :)

 Secondly you ask about getting the weekday of
 the month. There's already a function in
 DateTime for this:
 $dt-weekday_of_month();

Yes - but if we add the above functionality to DT::Span I think we should also have 
weekday_of_span() or a similar method for finding your location relativity to the 
start of the span (and not just the current month).

-J

--


RE: figuring out the number of sundays in a given year

2003-09-20 Thread Joshua Hoblitt
 I'm not sure about the count in a year, but I frequently need to
 determine how many of a given day of the week fall in a given month
 of the year, or, more precisely, given that today is Saturday,
 September 20, I need to figure out whether today is the first,
 second, third, fourth, or fifth Saturday of the month. I've worked
 out code using existing methods to tell me what I need to know, and
 I'm not sure that an entirely new method is warranted here.

To generalize:

You want to know how many of a given day occur in a range and at what position in that 
range a given datetime is?

This sounds like something that should operate on a DT::Span object.

-J

--


Re: figuring out the number of sundays in a given year

2003-09-19 Thread Joshua Hoblitt
 The day_of_week() method DOES NOT TAKE ARGUMENTS!

I wonder if it's worth the overhead of checking for extraneous parameters on all 
methods?

-J

--


Re: figuring out the number of sundays in a given year

2003-09-17 Thread Joshua Hoblitt
Hi Ron,

I'm a bit confused by your parameters to day_of_week().

This is the actual implementation from DateTime.pm

sub day_of_week { $_[0]-{local_c}{day_of_week} }

-J

--
 script=

 use strict;
 use warnings;
 use DateTime;

 my $dt = DateTime-new( year = 2001 );
 my $num = number_of_sundays($dt);
 print $num;

 sub number_of_sundays {

 my ($dt) = @_;
 my $dt2 = $dt-clone();

 if ( $dt-is_leap_year ) {

 my $dow = $dt2-day_of_week(
   year  = $dt-year,
   month = 1,
   day   = 1,
 );
 return 53 if ( $dow == 7 or $dow == 6 );

 }
 else {

 my $dow = $dt2-day_of_week(
   year  = $dt-year,
   month = 1,
   day   = 1,
 );
 return 53 if ( $dow == 7 );
 }

 return 52;
 }



DT strftime specifiers

2003-09-15 Thread Joshua Hoblitt
It's defined in the docs...

=item * %V

The ISO 8601:1988 week number of the current year as a decimal number,
range 01 to 53, where week 1 is the first week that has at least 4
days in the current year, and with Monday as the first day of the
week. See also %U and %W.

  'U' = sub { my $dow = $_[0]-day_of_week;
   $dow = 0 if $dow == 7; # convert to 0-6, Sun-Sat
   my $doy = $_[0]-day_of_year - 1;
   return int( ( $doy - $dow + 13 ) / 7 - 1 )
 },

But it's not here...

  'w' = sub { my $dow = $_[0]-day_of_week;
   return $dow % 7;
 },

Was it documented and then not implemented?

-J

--


DT 0.17 test failure on 5.8.1 RC4

2003-09-14 Thread Joshua Hoblitt
I was taking a look at what's currently in Redhat's 'Rawhide' and I discovered that 
DateTime 0.17 has test failures on their 5.8.1 RC4 build.

-J

--
Running make test
PERL_DL_NONLAZY=1 /usr/bin/perl -MExtUtils::Command::MM -e test_harness(0,
'blib/lib', 'blib/arch') t/*.t
t/00loadok
t/01sanity..ok
t/02last_dayok
t/03components..Invalid offset: -124
# Looks like you planned 122 tests but only ran 55.
# Looks like your test died just after 55.
t/03components..dubious
Test returned status 255 (wstat 65280, 0xff00)
Scalar found where operator expected at (eval 153) line 1, near 'int'  $__val
(Missing operator before   $__val?)
Operator or semicolon missing before typedef at (eval 156) line 1.
Ambiguous use of  resolved as operator  at (eval 156) line 1.
DIED. FAILED tests 56-122
Failed 67/122 tests, 45.08% okay
t/04epoch...ok
t/05set.ok
t/06add.ok
t/07compare.ok
t/09greg# this may take a minute...
t/09gregok
t/10subtractok
t/11durationok
t/12weekok
t/13strftimeok 41/126# New locale: de
t/13strftimeok 75/126# New locale: it
t/13strftimeok
t/14locale..ok
t/15jd..ok
t/16truncateok
t/17set_return..ok
t/18today...ok
t/19leap_second.ok
t/20infiniteok
t/21bad_params..ok
t/22from_doyok
t/23storableok
t/24from_object.ok
t/25add_subtractok
t/26dt_leapsecond_pmok
Failed Test  Stat Wstat Total Fail  Failed  List of Failed
---
t/03components.t  255 65280   122  134 109.84%  56-122
Failed 1/26 test scripts, 96.15% okay. 67/1483 subtests failed, 95.48% okay.
make: *** [test_dynamic] Error 255
  /usr/bin/make test -- NOT OK
Running make install
  make test had returned bad status, won't install without force

Summary of my perl5 (revision 5.0 version 8 subversion 1) configuration:
  Platform:
osname=linux, osvers=2.4.21-1.1931.2.393.entsmp, archname=i386-linux-thread-multi
uname='linux daffy.perf.redhat.com 2.4.21-1.1931.2.393.entsmp #1 smp wed aug 13 
21:51:41 edt 2003 i686 i686 i386 gnulinux '
config_args='-des -Doptimize=-O2 -g -pipe -march=i386 -mcpu=i686 -Dversion=5.8.1 
-Dmyhostname=localhost [EMAIL PROTECTED] -Dcc=gcc -Dcf_by=Red Hat, Inc. 
-Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr 
-Dsiteprefix=/usr -Dotherlibdirs=/usr/lib/perl5/5.8.1 -Duseshrplib -Dusethreads 
-Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm 
-Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl -Ubincompat5005 
-Uversiononly -Dpager=/usr/bin/less -isr'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
  Compiler:
cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING 
-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
-I/usr/include/gdbm',
optimize='-O2 -g -pipe -march=i386 -mcpu=i686',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING 
-fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm'
ccversion='', gccversion='3.3.1 20030811 (Red Hat Linux 3.3.1-1)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=4, prototype=define
  Linker and Libraries:
ld='gcc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
libc=/lib/libc-2.3.2.so, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version='2.3.2'
  Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic 
-Wl,-rpath,/usr/lib/perl5/5.8.1/i386-linux-thread-multi/CORE'
cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'


Characteristics of this binary (from libperl):
  Compile-time options: DEBUGGING MULTIPLICITY USE_ITHREADS USE_LARGE_FILES 
PERL_IMPLICIT_CONTEXT
  Locally applied patches:
RC4
  Built under linux
  Compiled at Aug 20 2003 09:16:46
  @INC:
/usr/lib/perl5/5.8.1/i386-linux-thread-multi
/usr/lib/perl5/5.8.1
/usr/lib/perl5/site_perl/5.8.1/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.1
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi

Re: [Patch] DT::TZ Offsets

2003-08-26 Thread Joshua Hoblitt
 Ok, I'm convinced.  Just go ahead and check it in as implemented.

Done.  I'll also add some tests for the 'name' normalization in OffsetOnly before the 
next release.

-J

--


Re: [Patch] DT::TZ Offsets

2003-08-22 Thread Joshua Hoblitt
 Can you change it so that the maximum offset is 24:00:00 and then check it
 in?

There's no official limit on offsets are there?  I can envision some small country 
declaring an offset of greater then 24hours.

-J

--


Re: [Patch] DT::TZ Offsets

2003-08-22 Thread Joshua Hoblitt
 Cuba (-0500) was at some point planning to change to +1900, to be the
 first country in the year 2000. If that would have happened, what do you
 think Kiribati (+1200, the first country to celebrate 2000 in reality)
 would have done? (They would have gone to +3600, of course; and perhaps
 even change back to +1200 at noon, 1 Jan 2000: celebrate the new
 millennium twice!!!).

I've actually been to Kiribati and at least Fanning island is +1400. :)

-J

--


Re: Subtraction Broken?

2003-08-22 Thread Joshua Hoblitt
  The only problem is that DT::subtract_datetime doesn't use it. It
  probably should. (It would be even better if there was an option to
  calculate the difference in days  secs. But the default should probably
  be to return a difference of months, days, minutes, seconds.)

 I think the default should probably be the accurate method, but I do think
 offering a way to return the other values would be good.

I'm a bit nervous about building that into DT::Duration.  If a resulting vague result 
is reused for date math someone could blow their foot off an not realize it.

-J

--


Re: [Patch] DT::TZ Offsets

2003-08-22 Thread Joshua Hoblitt
  There's no official limit on offsets are there?  I can envision some
  small country declaring an offset of greater then 24hours.

 You can?  That doesn't make much sense to me.  If it happens, we can
 change the code ;)

The universe doesn't always make sense to you? :)  I choose 99:59:59 as the offset 
limit as that's the maximum time value that can be represented by that number of 
digits.  If someone wants to specify an offset of  24 hours I'm willing to assume 
they know what they're asking.  It doesn't cause us any pain as it fits within the 
format we're already supporting.

Of course we could also optionally accept duration objects as offsets specifiers...  
That actually doesn't sound like a bad idea. :)

-J

--


[Patch] DT::TZ Offsets

2003-08-20 Thread Joshua Hoblitt
This patch started out as just adding some tests (taken from DT::TZ::Alias) but I 
uncovered several issues.

These currently accepted offset formats should be rejected as they are ambiguous:

'111', '+111', '-111',
'1:11', '+1:11', '-1:11',
'1', '+1', '-1',
'111:11', '+111:11', '-111:11',
'1:', '+1:', '-1:',
'1:11:11', '+1:11:11', '-1:11:11',
':11', '+:11', '-:11',
'11:', '+11:', '-11:',

- the hours value of an offset must be specified as 2 digits
- the colon separator must be used between both hours/minutes and minutes/seconds or 
not at all

The algorithm for turning an offset string into a number of seconds was taking a 
modulus of the hours value.  This could lead to developer surprise.  The hours value 
has been limited to 99 (what fits into 2 digits), minutes limited to 59, and seconds 
limited to 59.

- offset string formats are now validated and undef is returned for bad formats
- the modulus of the hours value is removed

The algorithm for turning a number of seconds into an offset string was producing 
floating point values.  These were not being seen because of the sprintf format but 
could be a problem in the future.

- internal floating point values are now truncated
- the input number of seconds is now limited to what can actually be formated into a 
valid offset string
- the output of offset_as_seconds() passed to offset_as_string() will return the 
original input (and vice versa)

The 'name' key of OffsetOnly objects was not being normalized.  Two objects with 
identical values but different 'names' could be created.

- the 'name' value is now normalized

Also:

- added more regression tests
- some minor cosmetic changes for clarity

Comments?

-J

--
Index: lib/DateTime/TimeZone.pm
===
RCS file: /cvsroot/perl-date-time/modules/DateTime-TimeZone/lib/DateTime/TimeZone.pm,v
retrieving revision 1.84
diff -u -r1.84 TimeZone.pm
--- lib/DateTime/TimeZone.pm10 Aug 2003 13:44:48 -  1.84
+++ lib/DateTime/TimeZone.pm19 Aug 2003 10:28:53 -
@@ -346,12 +346,16 @@

 return 0 if $offset eq '0';

-return undef unless $offset =~ /^([\+\-])?(\d\d?):?(\d\d)(?::?(\d\d))?$/;
+return undef unless $offset =~ /^([\+\-])?(\d\d)(:?)(\d\d)(?:\3(\d\d))?$/;
+
+my ( $sign, $hours, $minutes, $seconds ) = ( $1, $2, $4, $5 );

-my ( $sign, $hours, $minutes, $seconds ) = ( $1, $2, $3, $4 );
 $sign = '+' unless defined $sign;
+return undef unless $hours = 0  $hours = 99;
+return undef unless $minutes = 0  $minutes = 59;
+return undef unless ! defined( $seconds ) || ( $seconds = 0  $seconds = 59 );

-my $total =  ($hours * 60 * 60) + ($minutes * 60);
+my $total =  $hours * 3600 + $minutes * 60;
 $total += $seconds if $seconds;
 $total *= -1 if $sign eq '-';

@@ -363,17 +367,17 @@
 my $offset = shift;

 return undef unless defined $offset;
+return undef unless $offset = -35  $offset = 35;

 my $sign = $offset  0 ? '-' : '+';

 $offset = abs($offset);

-my $hours = $offset / ( 60 * 60 );
-$hours = $hours % 24;
-
-my $mins = ( $offset % ( 60 * 60 ) ) / 60;
-
-my $secs = $offset % 60;
+my $hours = int( $offset / 3600 );
+$offset %= 3600;
+my $mins = int( $offset / 60 );
+$offset %= 60;
+my $secs = int( $offset );

 return ( $secs ?
  sprintf( '%s%02d%02d%02d', $sign, $hours, $mins, $secs ) :
@@ -569,10 +573,12 @@

 Given an offset as a string, this returns the number of seconds
 represented by the offset as a positive or negative number.
+Returns Cundef if $offset is not in the range C-99:59:59 to C+99:59:59.

 =item * offset_as_string( $offset )

 Given an offset as a number, this returns the offset as a string.
+Returns Cundef if $offset is not in the range C-35 to C35.

 =back

Index: lib/DateTime/TimeZone/OffsetOnly.pm
===
RCS file: 
/cvsroot/perl-date-time/modules/DateTime-TimeZone/lib/DateTime/TimeZone/OffsetOnly.pm,v
retrieving revision 1.18
diff -u -r1.18 OffsetOnly.pm
--- lib/DateTime/TimeZone/OffsetOnly.pm 13 Jun 2003 17:50:57 -  1.18
+++ lib/DateTime/TimeZone/OffsetOnly.pm 19 Aug 2003 10:28:53 -
@@ -3,7 +3,7 @@
 use strict;

 use vars qw ($VERSION);
-$VERSION = 0.01;
+$VERSION = 0.02;

 use DateTime::TimeZone;
 use base 'DateTime::TimeZone';
@@ -24,7 +24,10 @@

 return DateTime::TimeZone::UTC-new unless $offset;

-my $self = { name = $p{offset}, offset = $offset };
+my $self = {
+name= DateTime::TimeZone::offset_as_string( $offset ),
+offset  = $offset,
+};

 return bless $self, $class;
 }
Index: t/05offset.t
===
RCS file: /cvsroot/perl-date-time/modules/DateTime-TimeZone/t/05offset.t,v
retrieving revision 1.2
diff -u -r1.2 05offset.t
--- t/05offset.t7 May 2003 

Re: Subtraction Broken?

2003-08-17 Thread Joshua Hoblitt
Hi Mattew,

 $birth=DateTime-new(year=1968,month=6,day=28);
 print $birth-ymd.\n;
 $today=DateTime-today;
 print $today-ymd.\n;
 $age=$today-$birth;
 print $age-years.\n;

$age is a DateTime::Duration object.   Unfortunately math with these object can be a 
little non-intuitive.

 I get this output:

 1968-06-28
 2003-08-17
 0

Try:

print $age-deltas, \n;

If the output from that doesn't look right to you please send it on to the list.

 That zero sure doesn't seem correct to me.

It means zero year 'units' - that doesn't preclude other 'units' adding up to year+ 
values.

Cheers,

-J

--


Re: Subtraction Broken?

2003-08-17 Thread Joshua Hoblitt
 Again I fail to see the logic or even value in the DateTime::Duration
 behaving as above. But, I'm sure I'm probably just missing something
 important.

Durations are independent of dates and times.

 The only one that does makes since is Deltas but only
 because it is returning a hash that has 10 elements in it. The Delta

If you would have used my example it would have printed all the hash keys and values.  
Your use of the concatenation operator forced scalar context so you ended up with the 
'10'.

 Days is sort of interesting but its seems like a lot of work for me
 to figure out the number of years from that especially when I think
 the point of this is to take into account all the strange ness that
 goes on between missing days seconds etc that go on over time.

Years relative to what?  Years are _not_ all the same length.  Nor are months, days, 
hours, or even minutes.  This is what makes this such a complicated problem.  I [we] 
understand your confusion but DT::Duration is correct.

 Perhaps I'm just approaching this all wrong. I'm just looking for a
 simple way to compute some ones age today.

What you want is to normalize the values of a duration relative to some fixed point in 
time.  I agree this is something that we need to do.  Patches are welcome. :)

-J

--


Re: DT::TZ test failure

2003-08-14 Thread Joshua Hoblitt
 Okay, so maybe a new constructor then?  DateTime-localtime()?  Getting
 the current local time seems more common than, say, constructing a
 DateTime object from a day of the year, IMO :)

We have enough constructors as it is.  I could be talked into:

DateTime-now( time_zone = 'local' );

But that would add extra overhead on every call to now();

Whats wrong with:

DateTime-now-set_time_zone( 'local' );

or

sub here_now { DateTime-now-set_time_zone( 'local' ) }

?

If your going to insist on another constructor you could write it as a decorator with 
our new plug-in architecture. :)

-J

--


Re: RFC: DateTime::TimeZone::LMT

2003-08-14 Thread Joshua Hoblitt
 Maybe there should be an extra accessor -link_name. (They're called
 links in the TimeZone innards). Then when -time_zone_short_name is
 called and it has no value, it return -link_name. Same for long_name.

I don't like that at all.  You really should be creating new classes with your 
specified short names.  Otherwise this might break somebody else's code that is 
relying on the default behavior.

-J

--


[patch] use DT in Astro::Sunrise

2003-08-14 Thread Joshua Hoblitt
Hi Ron,

Here is a 'eating our own dog food' patch against Astro::Sunrise 0.8. :)

Cheers,

-J

--
diff -ur Astro-Sunrise-0.8/Makefile.PL Astro-Sunrise-0.8.new/Makefile.PL
--- Astro-Sunrise-0.8/Makefile.PL   2003-02-27 05:05:20.0 -1000
+++ Astro-Sunrise-0.8.new/Makefile.PL   2003-08-06 19:02:35.0 -1000
@@ -4,5 +4,5 @@
 WriteMakefile(
 'NAME' = 'Astro::Sunrise',
 'VERSION_FROM' = 'Sunrise.pm', # finds $VERSION
-'PREREQ_PM' ={ 'Time::Piece' = 1.08, },
+'PREREQ_PM' ={ 'DateTime' = 0.16, },
 );
diff -ur Astro-Sunrise-0.8/Sunrise.pm Astro-Sunrise-0.8.new/Sunrise.pm
--- Astro-Sunrise-0.8/Sunrise.pm2003-02-27 05:10:32.0 -1000
+++ Astro-Sunrise-0.8.new/Sunrise.pm2003-08-06 19:10:29.0 -1000
@@ -82,7 +82,7 @@
 use POSIX;
 use Math::Trig;
 use Carp;
-use Time::Piece;
+use DateTime;
 #use Time::Seconds;
 use vars qw( $VERSION @ISA @EXPORT @EXPORT_OK $RADEG $DEGRAD );

@@ -579,20 +579,16 @@
my $alt = shift || -0.833;
my $offset = int( shift || 0 );

-   my $today = localtime;
-   #
-   # Not sure why appending a 'D' to the offset didn't work.  So converted
-   # the days into seconds...
-   #
-   $today = $today + $offset * 86400;
+   my $today = DateTime-today-set_time_zone( 'local' );
+   $today-add( days = $offset );

my( $sun_rise, undef ) = sunrise( $today-year, $today-mon, $today-mday,
  $longitude, $latitude,
- $today-tzoffset-hours,
+ ( $today-offset / 3600 ),
  #
- # DST is always 0 because Time::Object
- # currently (v 1.00) adds one to the
- # tzoffset during DST hours
+ # DST is always 0 because DateTime
+ # currently (v 0.16) adds one to the
+ # offset during DST hours
  0,
  $alt );
return $sun_rise;
@@ -635,20 +631,16 @@
my $alt = shift || -0.833;
my $offset = int( shift || 0 );

-   my $today = localtime;
-   #
-   # Not sure why appending a 'D' to the offset didn't work.  So converted
-   # the days into seconds...
-   #
-   $today = $today + $offset * 86400;
+   my $today = DateTime-today-set_time_zone( 'local' );
+   $today-add( days = $offset );

my( undef, $sun_set ) = sunrise( $today-year, $today-mon, $today-mday,
 $longitude, $latitude,
-$today-tzoffset-hours,
+( $today-offset / 3600 ),
 #
-# DST is always 0 because Time::Object
-# currently (v 1.00) adds one to the
-# tzoffset during DST hours
+# DST is always 0 because DateTime
+# currently (v 0.16) adds one to the
+# offset during DST hours
 0,
 $alt );
return $sun_set;


Re: DateTime-localtime() (was Re: DT::TZ test failure)

2003-08-14 Thread Joshua Hoblitt
 I think a constructor aimed at time_zone = 'local' makes sense. If not
 that, then perhaps a class variable for DEFAULT_TIMEZONE or somesuch.

DateTime-now( time_zone = 'local' );
vs.
DateTime-local_now;

Saves an incredible 18 characters even with generous spacing.

 Also, regarding the issue of 'local' not always working: I'm not
 convinced that hard-coding timezones into code is worth the tradeoff
 (configuring your local timezone every time you install a module, for
 instance).

That will lead to weird errors and a mess of portability issues.  Not to mention we 
don't want to support that mess.

 I'm not going to insist that now() default to this, but the addition of
 a constructor that does do this would personally save me a lot of typing.

Put a macro in your editor. :)

-J

--


Re: RFC: DateTime::TimeZone::LMT

2003-08-14 Thread Joshua Hoblitt
 What I want is the reverse of what alias does. Or rather I'd like
 timezone to remember what value it was created with. If I create an
 alias 'EST' = 'UTC' and then create a datetime with 'EST', I'd like to
 get EST as the name rather than UTC.

Awww - I understand what your asking for now.  We would have to provide some sort of 
registration facility in DT::TZ.

 What do people think? I can provide patches for this if I'm not the only
 one who'd find it useful.

Can you give an example of what this would be used for?

-J

--


Re: DT::TZ test failure

2003-08-14 Thread Joshua Hoblitt
 If you only have a year and day of year, then having a from_day_of_year
 constructor saves a _lot_ of calculation that end users have to do.  OTOH,
 having to do 'DateTime-now(time_zone = local)' isn't very onerous at
 all.

If you need an example DT::F::ISO8601 makes heavy use of from_day_of_year().

-J

--


Re: Re: [rfc] HiRes

2003-08-14 Thread Joshua Hoblitt
  So are we back to DT::HiRes?  Or just rename the constructor?  I would
  like to see this functionality make it into the next release.

 I guess sticking it in a separate module DateTime::HiRes works, since that
 way we don't force people to load Time::HiRes if they don't need it.

What about using 'require Time::HiRes' inside the hires constructor?  My thinking is 
since we already have hires_epoch() in the DT namespace we might as well have 
hires_now() there too.

-J

--


  1   2   3   4   >