Re: missing something..part 2

2007-01-25 Thread Ben Bennett
Or use DateTime::TimeZone::Alias [1]

(untested code follows)
  use DateTime::TimeZone::Alias

  for my $hr in (0 .. 12) {
DateTime::TimeZone::Alias-set(Etc/GMT+$hr, -${hr}:00);
DateTime::TimeZone::Alias-set(Etc/GMT-$hr, +${hr}:00);
  }
  # And don't forget the 15 minute offsets and the 30 minute offsets
  # Also, the offsets may go bigger than 12... check to see what you
  # have defined on your system

  Hehe. I'm the DBA. And I've updated everything to most recent stuff, 
 but the boss man wants generic time zones in our list just in case a 

He means the timezone database that is distributed with the perl
DateTime package, nor your (oracle/mysql/whatever) database.

 -ben

[1] 
http://search.cpan.org/~jhoblitt/DateTime-TimeZone-Alias-0.0501/lib/DateTime/TimeZone/Alias.pod


On Thu, Jan 25, 2007 at 04:18:02PM +, Zefram wrote:
 Matthew wrote:
  Hehe. I'm the DBA. And I've updated everything to most recent stuff, 
 but the boss man wants generic time zones in our list just in case a 
 customer can't find his or doesn't realize his city is listed differently.
 
 Unlikely to ever occur.  As far as anyone knows, the Olson zoneinfo
 database contains all currently-distinct timezones.  (It explicitly aims
 to include all timezones that have been distinct at any time since 1970.)
 You might want to play with the tzselect(8) program, which guides one
 through selecting a geographical timezone from the database.
 
 -zefram


Re: Latitude/Longitude to Olson timezone name

2004-03-28 Thread Ben Bennett
And to ask a nasty question... will it support localization?

Or I suppose if your mapping is from lat/long to TZ then the
localization problem will be in the code for taking a location name
and producing the lat/long.  Which makes this more tractable.

   -ben

On Sun, Mar 28, 2004 at 05:52:41PM -0600, Ed Perrone wrote:
 Thanks for all the suggestions.  I have been looking through the Olsen 
 distribution files (zone.tab, etc.), and was considering making up a 
 conversion table.  I just didn't want to re-invent the wheel if it had 
 already been done.
 
 Now, as for I need to figure out which of the Olsen zones Austin TX is 
 located in., I can offer a solution: Ask the user.
 
 Wel..  mebbe.  But you have to assume the user is dumb and doesn't 
 know.  :-)
 
 There is commercial software that does all this.  It is the International 
 Atlas, based on the Shanks time-changes books and published by the same 
 people.  I don't know what system they use for their lookups -- probably 
 some sort of internal conversion table of the same type we're discussing 
 here.  They charge mucho bucks for their software, especially for use in a 
 Web environment.
 
 Since no one has actually done it yet, I will go ahead and see if I can 
 make up some kind of a lookup/conversion table.  (I'm apparently going to 
 have to do this anyway for my client's project.)  I will make the results 
 available here, and if there's some way they can be integrated into 
 DateTime, I think it might make a lot of people happy.
 
 (Of course, that means such a table would have to be updated periodically, 
 to take into account political changes, etc.)
 
 Anyways, I will see what I can come up with and let y'all know.
 
 --- Ed
 
 
 
 Ed Perrone
 Interactive Web Development
 [EMAIL PROTECTED]
 http://www.edperrone.com
 


Re: DateTime::Stringify ...

2004-02-21 Thread Ben Bennett
Of course the overloaded stringification sub could look at its call
stack and see who was calling it and skip stringification if it was
Devel::StackTrace or Carp...  But that is _really_ gross.

  -ben

On Sat, Feb 21, 2004 at 04:01:39PM -0600, Dave Rolsky wrote:
 On Sat, 21 Feb 2004, Matt Sisk wrote:
 
  Hmmm, I guess not. At least, I couldn't get 'no overload' to do anything
  useful.
 
  How much of a PITA is it to use overload::StrVal and
  overload::Overloaded in Devel::StackTrace?
 
 Not a PITA at all, I just liked the other solution even more.
 
 
 -dave
 
 /*===
 House Absolute Consulting
 www.houseabsolute.com
 ===*/


Re: Calculate down time

2003-10-13 Thread Ben Bennett
Why do you hate me :-)

I have no idea how to handle this easily... is a bunch of sets the
right answer?  Seems gross.

   -ben

On Mon, Oct 13, 2003 at 01:00:09PM -0300, Flavio S. Glock wrote:
 How about a question for the FAQ?
 
 http://perlmonks.org/index.pl?node_id=298788
 
  Calculate down time of devices in prime time (only working hours, excluding 
  p_holidays)
   by albertc on Oct 13, 2003 at 05:00 GMT+3
 
  I have up  down datetime data for devices, I need a function that will provide the
  downtime within the primetime period. Input will be d_time, u_time, stime 
  (starting time
  for Primetime, 08:00:00), etime (endtime for PrimeTime, 18:59:59). The function 
  also
  needs to remove downtime that occured on a public holiday and over weekends! Public
  holidays will be read from mysql table with Datetime record of each public holiday.
 
 
 - Flavio S. Glock


Re: DateTime::TimeZone::POSIX

2003-09-25 Thread Ben Bennett
Not that I have seen.  This would be tricky to do right.  I don't
think you can make arbitrary timezones easily.

Ideally the right thing to do would be to parse the TZ string and
find the Olsen entry that matches it, then use the Olsen ID.

In the cases where that does not exist, then you would have to make a
timezone object up that represents the rules for the TZ.  Perhaps you
can simply do this each time you parse a TZ...

Nonetheless, I think being able to parse TZs would be a great thing
for the DT project.

   -ben

On Thu, Sep 25, 2003 at 12:49:00PM +0200, Claus Färber wrote:
 Hallo,
 
 is someone working on a module that takes timezone strings from the
 environment variable TZ as defined by POSIX:
 http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap08.html
 
 Claus
 -- 
 http://www.faerber.muc.de


Re: Olson - Microsoft mappings

2003-09-23 Thread Ben Bennett
I agree with Joshua's intent.  I think that the timezone selection
right now is the most difficult part of using DateTime if the user has
to specify it (and especially if you are not using a GUI).

I agree that changing DT::TZ is probably not the right thing to do.
Perhaps there should be a DT::TZ::Helper namespace?

I would also love a module that would set up appropriate
DT::TZ::Alias(es) for a given country.  So if I loaded
DT::TZ::Alias::Country qw(US); (or whatever) it would load EST as an
alias for America/New_York.

Finally, having the aliases US/Eastern makes a lot of sense to me.
Perhaps it would make sense to make equivalent alises for all of the
countries (possibly under a DT::TZ::Alias submodule).  So for
countries without different zones that is simply:
 China
 Britain
Then for countries with multiple zones:
 Australia/Eastern
etc.

  -ben

On Mon, Sep 22, 2003 at 10:31:38PM -1000, Joshua Hoblitt wrote:
  It's become painfully obvious that having end users choose
  a timezone based on the huge list that is provided natively
  by DateTime::TimeZone::all_names just isn't very practical
  at this time.  (Perhaps in the future when more people are
  used to dealing with the Olson names.)

..


Re: RFC: DateTime::TimeZone::LMT

2003-08-14 Thread Ben Bennett
No, I would like this too.

Perhaps the functionality can be rolled into DT::Alias somehow.  They
seem related...

-ben

On Tue, Aug 12, 2003 at 08:02:02AM +1000, Rick Measham wrote:

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


Re: long/lat - timezone map

2003-07-31 Thread Ben Bennett
I think it would be useful to make a set of TZ aliases per
country... like the US/Eastern, etc. stuff but for every country.

It would be even more useful to be able to break it down further as
needed (state by state and county by county as needed).  But that is a
lot of work.

-ben

On Fri, Aug 01, 2003 at 10:05:12AM +1000, Rick Measham wrote:
 At 9:42 AM +1000 1/8/03, Iain Truskett wrote:
 Does anyone know of a machine-readable map that can convert lat/lon
 to timezone?
 
 Mac uses a map, you click on the map and it tells you the time at 
 that place in the world. Of course it's closed source so we can't get 
 a copy of it :(
 
 I remember that this was asked somewhere else .. here or someplace 
 else. There's an online map at http://www.worldtimezone.com/ but it's 
 not 'clickable' to select a timezone.
 
 While converting a lat/lon to a timezone would be close to 
 impossible, I'm willing to work on a clickable HTML or Flash map.
 
 The problem with converting lat/lon is that countries are not 
 geometric shapes where it would be easy to determine if a particular 
 lat/lon is within that country.
 
 Cheers!
 Rick
 
 -- 
 
 There are 10 kinds of people:
   those that understand binary, and those that don't.
 
   The day Microsoft makes something that doesn't suck
 is the day they start selling vacuum cleaners
 
 Write a wise proverb and your name will live forever.
-- Anonymous
 


Re: Python's 'DateTime'

2003-07-30 Thread Ben Bennett
DateTime::Display::Calendar or
DateTime::Display::Calendar::Text (vs. HTML, etc.)

?

   -ben


On Tue, Jul 29, 2003 at 10:46:59PM -1000, Joshua Hoblitt wrote:
  Months ago I posted the beginings of a module that I called
  DateTime::Format::Calendar. The discussion that followed was that
  'format' was the wrong namespace, but the conversation ended there.
   (http://nntp.x.perl.org/group/perl.datetime/2488)
 
  I'm happy to continue working on this, and will upload it somewhere, but
  I need a name.
 
 DateTime::Calendar::Gregorian::Month?
 
 -J
 
 --


Strange errors when trying to fix DateTime::Event::Nameday

2003-07-30 Thread Ben Bennett
Ok, I am trying to fix the broken tests in DateTime::Event::NameDay
and am getting the error 'Span cannot start after the end in
DateTime::Span-from_datetimes'.  However my span looks perfectly
valid...

So I boiled it down to a simple test case:
--
#!/usr/local/lib/perl -w

use strict;

use DateTime;
use DateTime::Span;
use DateTime::Calendar::Christian;


my $dt1 = DateTime-new
( year   = 1752,
  month  = 1,
  day= 1,
  );
my $dt2 = DateTime::Calendar::Christian-new
( year   = 1755,
  month  = 1,
  day= 3,
  reform_date = $dt1,
  );

my $sp = DateTime::Span-new(start = $dt1, end = $dt2);
--

This gives me two types of error:
--
Use of uninitialized value in numeric ne (!=) at 
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/DateTime.pm line 1174.
Use of uninitialized value in numeric comparison (=) at 
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/DateTime.pm line 1174.
Span cannot start after the end in DateTime::Span-from_datetimes
--

What am I doing wrong?  (This is using the latest CVS versions of
things) and the relevant lines from DateTime.pm are:

-- ( marks line 1174).
 foreach my $component ( qw( utc_rd_days utc_rd_secs rd_nanosecs ) )
 {
return $dt1-{$component} = $dt2-{$component}
 if $dt1-{$component} != $dt2-{$component};
 }
--

Thanks,

-ben


Re: ANNOUNCE: DateTime 0.14

2003-07-28 Thread Ben Bennett
On Mon, Jul 28, 2003 at 07:04:12PM +0200, Eric Cholet wrote:
 Dave Rolsky wrote:
[...]
 But don't latin-1 and utf8 overlap for the first 255 chars anyway?
 
 No they don't. Common misconception it seems.

To clarify, UTF-8 and ASCII overlap, but any character with the high
bit set incicates that this is a multi-byte character in UTF-8 so the
extended characters in latin-1 can not match.

However, the first 255 characters in Unicode overlap with Latin-1, but
that is not really helpful since you are either using UTF-8 or a
constant multi-byte encoding and need to add the extra bytes...

-ben


Re: icu-xml parser deadlocks

2003-07-25 Thread Ben Bennett
Me too:
   This is perl, v5.8.0 built for i386-linux-thread-multi
   
   Linux ayup.limey.net 2.4.20-18.9 #1 Thu May 29 06:54:41 EDT 2003
   i686 athlon i386 GNU/Linux

-ben

On Fri, Jul 25, 2003 at 02:17:23AM -0500, Dave Rolsky wrote:
 On Thu, 24 Jul 2003, Joshua Hoblitt wrote:
 
  I still can't get DT::Locale's parser to run under Linux (seems happy
  with Solaris thou).  Has anyone else tried this under Perl 5.8.0 on
  x86/Linux?
 
 Works for me with that exact setup.
 
 
 -dav
 
 /*===
 House Absolute Consulting
 www.houseabsolute.com
 ===*/


DateTime::Format::Common questions...

2003-07-22 Thread Ben Bennett
Okay, I have renamed the module to DateTime::Format::Common and I am
getting ready to check in the rough version I have.

However I have a few questions I want to get resolved first:

 1) Will DateTime 0.14 be the first release with locale support?  If
so, when will you be bumping the version number (do you usually do
that just before release?)  I need that version of DateTime as a
dependency.

 2) Can I add the sub _date_parts_order to the locales?  I have the
patch to generate_from_icu that does this if you want to see it.


Longer term questions (these can be resolved after an initial
checkin):
 
 3) I think I need to have additional per-locale information
(i.e. AD/BC, AM/PM and now, today, and +- infinity).  While AD/BC
and AM/PM are in the current locale files I don't think they are
in a useful form since there are too many permissible variations.

So, I propose to per-locale additional information.  However, I am
not sure if it makes sense to augment the DT::Locale files or to
have a separate DT::F::C::Locale tree.  It might be wise to allow
for additional day and month name variations too.  Obviously it
should default to the DT::Locale stuff whenever possible.

Thoughts?


   -ben


Re: DateTime::Format::Common questions...

2003-07-22 Thread Ben Bennett
On Tue, Jul 22, 2003 at 11:36:13AM -0500, Dave Rolsky wrote:
 On Tue, 22 Jul 2003, Ben Bennett wrote:
 
   1) Will DateTime 0.14 be the first release with locale support?  If
 
 Yes, and yes.  I'll be releasing this stuff soon, I think.

Ok, in that case I will check it in with a dependency on .14 (which
will mean that you can't install it without warnings for a little while).
 
   2) Can I add the sub _date_parts_order to the locales?  I have the
  patch to generate_from_icu that does this if you want to see it.
 
 Sure, go ahead, but make it date_parts_order.  It'll be public, after
 all.

Will do.

 
   3) I think I need to have additional per-locale information
 
 So you plan to customize this for every locale?  Ambitious.

Well... No.  :-)  But I plan to have a way to set it for any locale
and I will impose upon the nice people on this list who speak other
languages to tell me the appropriate values for their locale.  For
ones we haven't done it will inherit the root locale value.

I am also going to make a decent attempt to do the right things with
the AM/PM and BC/AD strings.  (And I will probably accept the English
versions of those for all locales anyway).

  So, I propose to per-locale additional information.  However, I am
  not sure if it makes sense to augment the DT::Locale files or to
  have a separate DT::F::C::Locale tree.  It might be wise to allow
  for additional day and month name variations too.  Obviously it
  should default to the DT::Locale stuff whenever possible.
 
 It almost certainly belongs in the DT::Locale code.  I'll come up with a
 way to hook in our extra data to the generation process.  There's already
 something in the generator to override the ICU stuff when it's wrong, so
 it shouldn't be too hard.

Ok, if you don't get to it I will take a look sometime.  I assume that
you want this to come from a separate source than the ICU data?
Probably a new directory and file per-override?

   -ben


Re: DateTime::Format::Common questions...

2003-07-22 Thread Ben Bennett
I committed it this afternoon (just the Locale change not the Common
parser).

-ben

On Tue, Jul 22, 2003 at 11:27:13AM -1000, Joshua Hoblitt wrote:
2) Can I add the sub _date_parts_order to the locales?  I have the
   patch to generate_from_icu that does this if you want to see it.
 
  Sure, go ahead, but make it date_parts_order.  It'll be public, after
  all.
 
 And I need it for DT::F::DB2 as DB2 is locale sensitive.
 
 -J
 
 --


Re: Need help from Aussies for time zone stuff

2003-07-18 Thread Ben Bennett
Do they call the standard and summer times different things?

The current DT::TZ stuff and POSIX::strftime and date on Linux and
Solaris all say EST in January and July...  I have also seen it given
as EAST and EADT (actually I just checked www.worldtimezone.com and it
gives AEST, AES, EAST and EST all as possible variations... bah!).

Iain, which state do you live in, and what is the short TZ name in
January and July?  Also, how do you tell the times from Queensland
apart from those in Victoria during DST?

I wonder if Olsen has the wrong short names?  The notes at the bottom
indicate that is possible.

 -ben

On Fri, Jul 18, 2003 at 02:12:51PM +1000, Rick Measham wrote:
 At 2:09 PM +1000 18/7/03, Iain Truskett wrote:
[...]
 IIRC the entire East Coast used to be the same and called it 'Eastern 
 Standard Time' and 'Eastern Summer Time'. Of course, the states are 
 all different now, but still call it 'AEST' and 'AEDT'!


Re: RFC: DateTime::Complex

2003-07-18 Thread Ben Bennett
I like the idea (this is the partial date  time thing right?) but I
am not too sure about the name... unless you start dealing with times
with real and imaginary parts :-) (Not that I have any suggestions for
a name yet).

Regarding the interface would it be better to have:
--
  my $dtc1 = DateTime::Complex-new_undef();
  # I assume that DT::C-new() assumes 0 like DT-new()
  # but that DT::C-new(year = 2003, day = undef )
  # would give 2003-xx-01-T00:00:00?

  my $dtc2 = $dtc1-set( month = 12 );
  my $christmas = $dtc2-set( day = 24 );
   # Do these clone BTW or are $dtc1, $dtc2 and $christmas all refs
   # to the same object (like DateTime does)?

  my $december = $christmas-set(day = undef);

  print $december-datetime;
  # -12-xxTxx:xx:xx

  # See above question re cloning objects.
  print $christmas-next( DateTime-now )-datetime;
  # 2003-12-24Txx:xx:xx

  my $xmas_noon = $christmas-clone()-set( hour = 12 );

  print $christmas-contains( $xmas_noon );
  # 1
--

Regarding the cloning question, it is more like DateTime if they do
not get cloned autmomatically, but I am assuming your implementation
is based on your DT::Set which I think does clone automatically?  I
would still vote for not cloning.

-ben

On Fri, Jul 18, 2003 at 11:15:30AM -0300, Flavio S. Glock wrote:
 RFC: DateTime::Complex
 
   use DateTime;
   use DateTime::Complex;
   use strict;
 
   my $dtc1 = DateTime::Complex-new_undef;
 
   my $dtc2 = $dtc1-define_month( 12 );
   my $christmas = $dtc2-define_day( 24 );
 
   my $december = $christmas-undef_day;
 
   print $december-datetime;
   # -12-xxTxx:xx:xx
 
   print $christmas-next( DateTime-now )-datetime;
   # 2003-12-24Txx:xx:xx
 
   my $xmas_noon = $christmas-define_hour( 12 );
 
   print $christmas-contains( $xmas_noon );
   # 1
 
   [some too-weird examples removed]
 
 :)
 - Flavio S. Glock


Re: RFC: DateTime::Complex

2003-07-18 Thread Ben Bennett
What were your thoughts on the constructor?  I think people expect a
new, but are unspecified things 0 (like DateTime) or undefined?

Also, what happens when you compare dates (or is that simply not
defined?).

Now that I think about it, you will probably need contains,
intersects, etc.  But I assume you already planned that.

For the name, my thoughts are:
DT::Partial
DT::Incomplete
DT::Reduced

Is it useful to have an optional base DT that can be used when an item
is undefined (to more easily allow Time only objects):
--
  my $dtw = DateTime::Whatever-new
  (hour = 10, minute = 5, second = 2);
  my $dt = DateTime-new(year = 2003, month = 7, day = 18);
  
  $dtw-set( base = $dt );

  print $dtw-year; # 2003
--

If you do that it may also be useful to have a method fix() (or
get_datetime() or flatten() or something) that returns a DateTime
either using the current base datetime, a provided datetime, or now()
(perhaps today()).  This would make it convenient as a the thing to
return from formats where there can be missing information:
--
  ...
  my $dt = DateTime::Format::Whatever-parse_datetime(12:30)
  -flatten();
  ...
--

Or am I off my rocker?

 -ben

On Fri, Jul 18, 2003 at 12:54:55PM -0300, Flavio S. Glock wrote:
 Yes, this is better:
 
$dtc1-set( month = 12 );
$dtc1-set( month = undef );
 
 It can work without cloning, in order to be compatible with DateTime
 API.
 
 Name - how about DateTime::Whatever ? (I like it)
 
$date = DateTime::Whatever-whatever( year = 2003 );
# 2003-xx-xxTxx:xx:xx
 
$date = DateTime::Whatever-new( year = 2003, day = undef )
# 2003-xx-01-T00:00:00
 
 And this is one of the lines I snipped from the previous mail:
 
$date-add( months = 12 )
# 2004-xx-01-T00:00:00
 
 - Flavio S. Glock
 
 
 Ben Bennett wrote:
  
  I like the idea (this is the partial date  time thing right?) but I
  am not too sure about the name... unless you start dealing with times
  with real and imaginary parts :-) (Not that I have any suggestions for
  a name yet).
  
  Regarding the interface would it be better to have:
  --
my $dtc1 = DateTime::Complex-new_undef();
# I assume that DT::C-new() assumes 0 like DT-new()
# but that DT::C-new(year = 2003, day = undef )
# would give 2003-xx-01-T00:00:00?
  
my $dtc2 = $dtc1-set( month = 12 );
my $christmas = $dtc2-set( day = 24 );
 # Do these clone BTW or are $dtc1, $dtc2 and $christmas all refs
 # to the same object (like DateTime does)?
  
my $december = $christmas-set(day = undef);
  
print $december-datetime;
# -12-xxTxx:xx:xx
  
# See above question re cloning objects.
print $christmas-next( DateTime-now )-datetime;
# 2003-12-24Txx:xx:xx
  
my $xmas_noon = $christmas-clone()-set( hour = 12 );
  
print $christmas-contains( $xmas_noon );
# 1
  --
  
  Regarding the cloning question, it is more like DateTime if they do
  not get cloned autmomatically, but I am assuming your implementation
  is based on your DT::Set which I think does clone automatically?  I
  would still vote for not cloning.


Re: DateTime parse(), parser()

2003-07-16 Thread Ben Bennett
On Wed, Jul 16, 2003 at 10:15:46AM -0400, John Siracusa wrote:
[snip]
 IMO.  Also, I don't think DT::Infinite is in the same boat, because
 that is a legitimate date (that DT::F::Simple must parse, BTW:
 /^([-+])?inf(?:inity)?$/i).  Returning DT::Infinite is not an error!

Is infinity really a simple date?  I think no.  Anyone else want to
weigh in?

   -ben


Re: DateTime parse(), parser()

2003-07-16 Thread Ben Bennett
Well, I don't think that the simple is supposed to indicate simple to
parse (at the moment the parser is all but simple... but I am trying
to clean it up).  I read it as simple formats, i.e. common formats
that define the date and time in fairly straightforward ways (month names
and numbers for things are fine, next week third thursday in the
next month with a blue moon are not).

The other problem I see is that your regexp only covers English
speaking locales...  I am currently using the DateTime::Locale date to
get locale sensitive information for parsing month and day names.
(Although AM/PM and BC/AD are a bit of a problem, I may need to add
extra information somewhere).

-ben

On Wed, Jul 16, 2003 at 11:30:33AM -0400, John Siracusa wrote:
 On 7/16/03 11:21 AM, Ben Bennett wrote:
  On Wed, Jul 16, 2003 at 10:15:46AM -0400, John Siracusa wrote:
  [snip]
  IMO.  Also, I don't think DT::Infinite is in the same boat, because
  that is a legitimate date (that DT::F::Simple must parse, BTW:
  /^([-+])?inf(?:inity)?$/i).  Returning DT::Infinite is not an error!
  
  Is infinity really a simple date?  I think no.  Anyone else want to
  weigh in?
 
 Either way, I'll weigh in again! :)  Of course it's simple because, in the
 context of DT::F::Simple, simple means simple to parse.  And this is
 pretty darned simple, IMO:
 
   if(/^([-+])?inf(?:inity)?$/i)
   {
 if($1 eq '-')
 {
   return DateTime::Infinite::Past-new;
 }
 
 return DateTime::Infinite::Future-new;
   }
 
 -John


Re: DateTime::Format::Simple and Indication of month/day/year or d/m/y in Locales...

2003-07-15 Thread Ben Bennett
On Tue, Jul 15, 2003 at 01:56:53PM +1000, Iain Truskett wrote:
 * Ben Bennett ([EMAIL PROTECTED]) [15 Jul 2003 13:10]:
[...] 

 My quibble; the name. I'm not a huge fan of ::Simple and ::Lite.
 Unfortunately, I can't think of a nice alternate for it.

Ok. I will think about that (suggestions welcomed).
 
 Sounds good. Ignoring unknown day names?

I think so.  I haven't decided yet.

  Ommissions from Date::Parse:
   - July 14th will not be parsed (I don't have localized info on the
 numeric suffixes)
 
 How about you just assume /\d{1,2}\w+/?

Perhaps, I will play with it when the rest is finished.  Input from
people who speak other languages would be appreciated.  I think that
would be okay in French, I am a bit concerned about how it behaves
with non-Latin languages.
 
  This will use the DT::F::Locales to get the localized forms of the
  days and months.
 
 What happens in the event of input being in an unknown locale? As in we
 don't know what locale this is in rather than we don't have locale
 data for xy_XX.

Erm... maybe later I will make something that can deal with ambiguous
locales.  That seems like a non-Simple.pm task (I realize that it
isn't that hard to do, but may be slow).
 
 Not really. The best one can do is have it so dates that can only be one
 type and not the other are done correctly. Ambiguity is part of the
 reason ISO8601 and W3CDTF have their order specified and why rfc(2)822
 uses the month _name_.

If you have the locale then I think you should be able to assume
ordering.
 
 If Simple is to be simple, I'm not sure it can really handle such
 things. The idea of Simple modules is to have as little of an
 interface as possible. Inner complexity and outer simplicity.

See above.

-ben


Re: DateTime::Format::Simple and Indication of month/day/year or d/m/y in Locales...

2003-07-15 Thread Ben Bennett
On Tue, Jul 15, 2003 at 12:14:00AM -0400, John Siracusa wrote:
 On 7/14/03 11:10 PM, Ben Bennett wrote:
[...]
 Sweet, someone took the bai--...er, picked up the baton ;)

Well I have been playing around with the idea for a while, but when
the locale stuff got in I decided it was time to stop fiddling and get
something useful together.
 
 I'm sure you're already doing this, but just in case, make sure to allow for
 single-digit numbers where there is no ambiguity.  This is essential for
 handling user-created input.  Examples:
 
 9/3/2002 (e.g. don't require 09/03/2002)
 1:02 (e.g. don't require 01:02)

Yes.

 and maybe even:
 
 200210131:02

No!  Egads :-)  Actually I wasn't accepting the form 200210130102
either (I will accept 20021013T0102).  Should I?

 but that may make some people break out in hives, so whatever :)

Scratch, scratch...

 Also,
 don't forget about the optional . in a.m. and p.m.  I'm not quite sure
 how that'd get localized, but the point is that the localized am/pm thingies
 must be regexes, not constant strings (or, okay, a regex constructed out of
 a list of constant strings, if you want :)

Yeah, I was trying to work that out.  It appears not to be in the raw
locale data, so I was considering just accepting the am/pm stuff with
optional inserted periods, even for other locales.  I still have to
survey all locales to see if that is even reasonable.  The other
choice would be to special case BC and AD to allow the dotted form,
but that seems a bit restrictive.
 
  Which leads to my problem, there appears to be no simple way to get
  the date order to differentiate m/d/y from d/m/y.
 
 Don't.  Make it a setting.  I've been trying to think of what to name this
 setting, but have no good ideas.  Here are some bad ones instead:

It would be a setting... locale.

 DT::F::Simple-use_mmdd(1);
 DT::F::Simple-use_ddmm(1);
 
 DT::F::Simple-mode('us');
 DT::F::Simple-mode('euro');
 
 DT::F::Simple-euro_mode(1);
 DT::F::Simple-us_mode(1);
 
 Gah, that's horrible :)  Someone out there must have some sort of
 pre-existing vocabulary to describe the date format differences.  Is it just
 regional, or are there ISO numbers to reference or what?

I can add an optional additional parameter dmy_mode (defaults to your
locale if undef) but I really think inferring it from the locale is
fine.

Speaking of which, what interface do people want?

  my $us_parser = DateTime::Format::Simple-new(locale = en_US);
  my $dt = $us_parser-parse_datetime(2/11/74);

Or:

  my $dt = DateTime::Format::Simple-parse_datetime(string = 2/11/74,
locale = en_US);

Note that it will always be legal to call:
  my $dt = DateTime::Format::Simple-parse_datetime(2/11/74);

And some locale will be assumed (probably en_US).

Another choice would be to allow both forms (which I may do to allow
user flexilbility).

-ben


Re: DateTime::Format::Simple and Indication of month/day/year or d/m/y in Locales...

2003-07-15 Thread Ben Bennett
On Mon, Jul 14, 2003 at 11:39:37PM -0500, Dave Rolsky wrote:
 On Mon, 14 Jul 2003, Ben Bennett wrote:
 
  Which leads to my problem, there appears to be no simple way to get
  the date order to differentiate m/d/y from d/m/y.  I can look at the
  time formats and try to work it out, but that seems a bit dodgy if you
  ever change the parser, plus I assume that I am not the only person
  who will want to know that.  So could we break it out as an explicit
  method?
 
 We'd have to look at the _actual_ format strings to do this, but it's
 certainly possible.

Ok, I will play around with this and see if all of the locales have
understandable short forms.

 
  Also the start of week infomation (and the weekend start and end) seem
  pretty useful for the financial stuff.  Would it be reasonable to add
  them to the Locale objects?
 
 Probably.

Cool, I may add that in the future if needed.

-ben


Re: DateTime::Format::Simple and Indication of month/day/year or d/m/y in Locales...

2003-07-15 Thread Ben Bennett
On Tue, Jul 15, 2003 at 11:40:16AM -0500, Dave Rolsky wrote:
 On Tue, 15 Jul 2003, Ben Bennett wrote:
 
 
 Actually, I was thinking that this would be done when generating the
 locale modules.  It shouldn't be _too_ hard, I think.

Sorry, that was where I was intending to fiddle with, I just wanted to
make sure it was possible to do it for all of the locales (or at least
a reasonable number of them).
 
 Again, see above.  You're welcome to tweak the generator code in the
 DateTime::Locale CVS.

Cool.

-ben


ICU data and date formats...

2003-07-15 Thread Ben Bennett
A bunch of the locales (e.g. ar_SY) have no date formats, but have
other stuff defined so they pass the has_data() check.

In this case I think they should inherit from their parent (ar).

However, there are some base languages (e.g. az) which have no date
format information defined but their sole child (e.g. az_AZ) has them.
The problem in this case is that the dates defined by az_AZ are of the
form dd.MM., but root is M/d/yy so simply inheriting the root one
is probably incorrect.

So I propose the following:
 A) If a locale (specified by language and territory) has no date
format then it should inherit that of the language
 B) If a language has no date format then no date format can be
determined.  For the DT::F::Simple stuff that will mean that there
is no default month and day ordering, so it will throw an error
unless one is provided separately.

Does this make sense?

I think A can be implemented by simply changing the subclass not to
generate a date_formats sub since it ISA the parent class.

I have not looked to see if there is a similar issue with month and
day names not being defined, but I assume that there is.  I assume
that a similar fix will be sufficient if there is a problem.

Thoughts?

-ben


Changable locale data...

2003-07-15 Thread Ben Bennett

DateTime::Locale objects return references to internal data.  So if a
caller changes things through the ref subsequent calls will see the
bogus data.

I am not sure if this is a problem or not, but we should at least
document that the caller _must_not_ change things through the ref.

  -ben


Another wrinkle...

2003-07-15 Thread Ben Bennett

It turns out that a handful of locales (e.g. af_ZA, en_ZA, fa, hr, hu,
ja ...) have dates with the form y/m/d.

So it looks like the value for the date component order (and the
optional parameter to DT::F::Simple) should be a string that can take
the 3 values:
   'ymd'
   'dmy'
   'mdy'

Does this make sense?

   -ben


Re: ICU data and date formats...

2003-07-15 Thread Ben Bennett
On Tue, Jul 15, 2003 at 01:22:36PM -0500, Dave Rolsky wrote:
 On Tue, 15 Jul 2003, Ben Bennett wrote:
[...]
 
 As long as the fact that everything defaults to 'root' (which is basically
 'en_US') is well-documented, I don't see a problem.
 
 What you're proposing would mean that for many locales, there would be
 _no_ date formats, which will just cause random breakage when people try
 to use something like $dt-strftime('%c').  Having this randomly throw
 exceptions is not a good thing.

Oh damn.  My instrumented version of generate_from_icu was changing
the behvior so I was ending up with an empty %time_formats structure
that I thought would cause problems.

So it looks like your code is doing part A already and you are of
course correct that everything should inherit from root to make sure
that the strftime behavior is reasonable.

Sorry all,

   -ben


Re: Ambiguous years (what does 03 mean?)

2003-07-15 Thread Ben Bennett
I think all that page is propsing is using the date of the file
creation rather than the current date.  Both windows 'move'.

I suppose I can consider adding a year parameter to the thing (at some
point in the future, first I want to get the basic functionality
working without too many feeping creatures).  Also I will consider a
pedantic flag that will enable some warnings about ambiguous dates (or
perhaps a flag to prevent use of ambiguous dates).  But that will all
be later...

-ben

On Tue, Jul 15, 2003 at 02:42:02PM -0400, John Peacock wrote:
 Dave Rolsky wrote:
 
 I think the standard is something along the lines of:
 
   if ($year + 50  ($current_year - 2000)) { $year += 1900 } else { $year 
   += 2000 }
 
 
 Except that this will probably be wrong when used to convert birthdates of 
 retirees (actual project I had to deal with, BTW).  See:
 
   http://www.dmi.uiuc.edu/y2k/window.htm
 
 for a way to handle moving windows.
 
 The two digit year format is so pernicious that it demands a warning in 
 pretty much all cases, and an error in any situation where the data is 
 important.
 
 John
 
 -- 
 John Peacock
 Director of Information Research and Technology
 Rowman  Littlefield Publishing Group
 4501 Forbes Boulevard
 Suite H
 Lanham, MD  20706
 301-459-3366 x.5010
 fax 301-429-5748


Re: DateTime::Format::Pg problem

2003-07-15 Thread Ben Bennett
fractional_seconds is deprecated...  nanoseconds have to be specified
separately.

I dunno if Pg has been updated to use the new interface yet.

  -ben

On Tue, Jul 15, 2003 at 12:30:39PM -0700, Alex Boster wrote:
 DateTime::Format::Pg dies when I parse an ISO date.  Can anyone point me
 in the right direction?  I looked at the module's code, and I can't find
 the problem.  The regex should match and fractional_seconds is in fact
 on the params list.
 
 [EMAIL PROTECTED] aboster]$ cat dt_test.pl
 #!/usr/local/bin/perl -w
 
 use DateTime;
 use DateTime::Format::Pg;
 use strict;
 
 my $str = '2003-07-14 09:37:33-07';
 my $d = DateTime::Format::Pg-parse_datetime($str);
 print Dumper(\$d);
 
 [EMAIL PROTECTED] aboster]$ ./dt_test.pl
 The following parameter was passed in the call to DateTime::new but was
 not listed in the validation options: fractional_second
  at
 /usr/local/lib/perl5/site_perl/5.8.0/DateTime/Format/Builder/Parser/Regex.pm line 135
 [EMAIL PROTECTED] aboster]$
 
 Since there are warnings in the docs about setting a timezone, I have
 also tried instantiating the a DateTime::Format::Pg object with the
 server_tz set and then calling the parse_timestamptz function.  The
 behavior is the same. (No surprise as this is the first parser tried by
 the more general function above.)
 
 This is DateTime::Format::Pg version 0.04.
 
 Thanks in advance,
 Alex
 
 PS: Here's hoping I haven't missed something really obvious and am
 making a public spectacle of it...


Re: The arguement for time-only.

2003-07-13 Thread Ben Bennett
I vote that you assume the next valid instance of the time (e.g. if
they say 4 o'clock and it is 11 PM now, assume 4AM of the following
day).

I believe this is what Date::Manip does and it seems to be reasonable
most of the time.

As another possibility (which is what I did with my obsolete version
of the ISO8601 parser) is to optionally take an arbitrary DT object to
use as the base and fall back to today otherwise.

I also returned additional items in array context, the first was the
DT object and the additional items described what was parsed so if the
person cared about time only in some cases they could tell them apart
from the fully specified items.

Additionally I allowed the user to tell the parser what formats were
valid.  I don't know if that is applicable in this parser though.

-ben

On Mon, Jul 14, 2003 at 08:19:07AM +1000, Rick Measham wrote:
 I'm working with DateTime::Format::Natural and I really need a time-only
 object. In fact I need an object that lets me chose what I want to give
 it. 
 
 For example: It was 12 o'clock - we know from this the hour, minute
 and second but have no idea of the day, month or year.
 
 Also: It was June 25 - no year, no time, but a valid date
 none-the-less. Sure there's some date math we can't do with it but we
 can still format it.
 
 What should I do with these? Currently I'm returning -01-01 00:00:00
 and subing in the parts I do know, but this is just wrong!
 
 Cheers!
 Rick


Re: DateTime::Format::ISO8601 namepsace

2003-07-06 Thread Ben Bennett
On Sat, Jul 05, 2003 at 06:56:32PM -1000, Joshua Hoblitt wrote:
 I want to preserve the revision history of my tree so the move to SF won't be until 
 next week.

Ok.

 What really needs to be done is a lot more tests.  I'm considering a framework for 
 building tests.

Ok, I can try to port over my framework when your code is checked in,
although it relies on being able to pass in a base date and be able to
select the return classes so I am not sure how easy it is to do.

  I have some additional functionality that I think is critical:
   1) The ability to say which pieces of the ISO spec are applicable
  (otherwise you can not tell the formats with leading -s apart from
  the ones with expanded years).  Also you need to be able to
  specify the number of additional years
 
 The simple solution is parse_time - a better one is coming.

What is your proposed API?  From the discussion on the DT list Dave
preferred extra arguments to parse_datetime which is what I ended up
implementing.

   2) Return information about the matching format so that you can tell
  which information is ommitted in the reduced formats.  (e.g. I
  want to be able to tell the year 2003 apart from Jan 1 2003.
 
 I agree but we don't have attributes for DT yet.

Yes, but you don't need them.  In the interface discussion Dave said
using wantarray() and returning extra fields was fine.

  Then some other information that would be nice:
   3) Return the parts of the string that matched (in addition to 2
  above, this makes handlind reduced formats more pleasant, rather
  than having to infer the week number from a returned DateTime).
 
 Return how?

My module had the return signature
  ($datetime_object, $format_info, $parsed_parts) = parse_datetime( ... )

   4) The ability to specify an arbitrary base date for the implied
   computations and times
 
 I agree with this.  But what is there now works well...

I disagree.  When I am dealing with a time I need to be able to say
what date is implied.

  I also think you will need 3 to support durations that have the form
  of a date (especially since they may not be valid dates if parsed by
  DateTime, e.g. P0002-02-30, for a duration of 2 years, 2 months and 30
  days).
 
 Invalid dates should raise an exception.  I'm not sure what to do about the longer 
 then 1 year problem.  My thinking is a DT::Duration::Set with multiple durations but 
 the whole thing is fuzzy right now.

No, I think you misunderstand.  They are not invalid dates because
they are not dates.  The duration format has 2 valid syntaxes, one is
the explicit P2Y2M30DT4H5M6S syntax, the other specifies them as if
they were dates, so the above period can also be P00020230T040506
which is a valid duration, but an invalid date if you use your date
parser to parse it rather than duplicate the formats.

c) Your fractional_hour does not compute seconds and nanoseconds
(i.e. T10.412342 gives precisely 10:24:00)
 
 Hmm... I'm not sure that this is wrong.  The spec is kinda vague.

Fair enough.

d) Your parse_time only parses the ambiguous time formats, some time
   formats are only in parse_datetime
 
 This is the same as your point #1.

I don't think so.  All I am saying here is that some time formats are
only parsable with parse_datetime and others with parse_time.  I would
have expected all time formats to be parseable with parse time and not
with parse_datetime (unless perhaps they had a leading T).
 
  Other issues (that I didn't solve either):
i)  You assume that a minute is 60 seconds in the fractional code
ii) For fractional durations, how do you represent .3 of a month?
   (The best answer I could come up with was to use the base date or
   today to get the number of days in a month).
 
  Sure, but how much further is it worth bending DT::F::Builder to
  handle this finicky standard?
 
 A lot. :)  This isn't the only weird standard.

No, my point is how far should it bend specifically for this standard?

   As I've said from the beginning I think your parser is very interesting and I 
   don't want to see you abandon it.  Perhaps it should be extracted from the 
   ISO8601 specific stuff and rolled into a stand alone module for specifying 
   date/time formats.  Maybe DateTime::Format::Grammar?
 
  I honestly don't think it is usefull outside of the context of
  ISO8601, it has a lot of the odd ISO stuff baked into it and if you
  were to do a generic Grammar then DT::F::Builder is a simpler base
  (unless you need lots of odd semantics in which case it is probably
  better to roll your own).
 
 I don't think you could write a Date::Manip replacement in DT::F::Builder yet.  Your 
 parser would be pretty good for this.

I agree with the first point, but I am not sure about the second.

 -ben


Re: DT::Duration::Set

2003-07-05 Thread Ben Bennett
Can you expand on this please?

-ben

On Sat, Jul 05, 2003 at 04:31:12AM -0400, Matt Sisk wrote:
 Dave Rolsky [EMAIL PROTECTED]:
  Can you and/or Joshua explain what this would be used for?
 
 elbowing in
 
 Unbounded clocks?
 
 Matt


Re: DateTime::Format::ISO8601 namepsace

2003-07-05 Thread Ben Bennett
On Fri, Jul 04, 2003 at 09:11:22AM -1000, Joshua Hoblitt wrote:
 I'm planning on moving my tree to SF CVS as soon as I return from OSCON.  Then we 
 can merge as much as we can from your tree into mine.

I assume you have a personal CVS repository?  Otherwise you can just
cvs add it over...
 
 A new version was sent to CPAN last night.  A road-map was sent to the list along 
 with the release.  Basically the next release will be bug fixes and more tests - 
 hopefully a thousand or more new tests.  Then the ISO section 5.5 stuff can be 
 started on.  I'm planning on working with Iain and Flavio for any changes needed to 
 DT::F::Builder or DT::Duration::Set (when it's written).

Sorry, I skipped over that message.  I dug it up and read it.

I have some additional functionality that I think is critical:
 1) The ability to say which pieces of the ISO spec are applicable
(otherwise you can not tell the formats with leading -s apart from
the ones with expanded years).  Also you need to be able to
specify the number of additional years
 2) Return information about the matching format so that you can tell
which information is ommitted in the reduced formats.  (e.g. I
want to be able to tell the year 2003 apart from Jan 1 2003.

Then some other information that would be nice:
 3) Return the parts of the string that matched (in addition to 2
above, this makes handlind reduced formats more pleasant, rather
than having to infer the week number from a returned DateTime).
 4) The ability to specify an arbitrary base date for the implied
 computations and times

I also think you will need 3 to support durations that have the form
of a date (especially since they may not be valid dates if parsed by
DateTime, e.g. P0002-02-30, for a duration of 2 years, 2 months and 30
days).


Bugs that I have noticed:
  a) The parser allows partial extended form on the times, so it takes
 12:3000...
  b) It does not allow all combined date and time formats that are
 legal (any non-truncated date and any non-reduced time
 combination is legal), also the whole expression must be either
 entirely in basic or expanded form (not mixed)
  c) Your fractional_hour does not compute seconds and nanoseconds
  (i.e. T10.412342 gives precisely 10:24:00)
  d) Your parse_time only parses the ambiguous time formats, some time
 formats are only in parse_datetime


Other issues (that I didn't solve either):
  i)  You assume that a minute is 60 seconds in the fractional code
  ii) For fractional durations, how do you represent .3 of a month?
 (The best answer I could come up with was to use the base date or
 today to get the number of days in a month).


 By collaborating with Iain while working on my ISO parser many very useful features 
 have been incorporated into DT::F::Builder.  I'd like to continue along this path as 
 it has potential benefits for other authors.  Of course your help is welcomed.

Sure, but how much further is it worth bending DT::F::Builder to
handle this finicky standard?

 As I've said from the beginning I think your parser is very interesting and I don't 
 want to see you abandon it.  Perhaps it should be extracted from the ISO8601 
 specific stuff and rolled into a stand alone module for specifying date/time 
 formats.  Maybe DateTime::Format::Grammar?

I honestly don't think it is usefull outside of the context of
ISO8601, it has a lot of the odd ISO stuff baked into it and if you
were to do a generic Grammar then DT::F::Builder is a simpler base
(unless you need lots of odd semantics in which case it is probably
better to roll your own).

-ben


Re: DateTime::Format::ISO8601 namepsace

2003-07-04 Thread Ben Bennett
So is there any conclusion here?  Should I commit my module or will
Joshua commit his?

-ben


Re: DateTime::Format::ISO8601 namepsace

2003-07-03 Thread Ben Bennett
Well mine currently does that and parses durations...

Joshuas can probably be changed to do so, but I am not motivated to
do the work.

  -ben

On Thu, Jul 03, 2003 at 10:13:04AM -0500, Dave Rolsky wrote:
 On Thu, 3 Jul 2003, Ben Bennett wrote:
 
  I am okay with this decision.  However Joshua's parser does not allow
  selection of which pieces of the spec are applicable so you can have
  ambiguous cases.
 
  Anyway, I will rename my parser to
  DateTime::Format::ISO8601::Complete and release it.
 
 Ugh, no.  Please, let's just have one parser.  Can't we have one that, by
 default, parses all the common, unambiguous cases, and also allows you to
 specify additional info so that ambiguous formats are parsed as well?
 
 
 -dave
 
 /*===
 House Absolute Consulting
 www.houseabsolute.com
 ===*/


DateTime::Format::ISO8601 interface questions...

2003-07-03 Thread Ben Bennett

I am not sure what interface to use for the advanced features of the
ISO8601 parser I wrote.  Right now I use a quick hack to make it work
so I can test the parser.  It should be easy for me to change the
interface to something sane, I just don't know what that should be.

The basic usage should be:
--
my $iso = DateTime::Format::ISO8601
my $dt = $iso-parse_datetime(20030211);
--

However, I want to be able to accept the following optional arguments:
 - The classes of formats to parse (Dates, Times, DateTimes,
   Durations, Recurrences)
 - The base DateTime object to use when things are implied (e.g. the
   date component when dealing with times, or any Truncated format,
   and some recurrences)  If not supplied this defaults to now().
 - The types to allow (each group is independent so you can have a
   Basic, Reduded, Week, Fractional, Expanded DateTime format):

   - Basic (no separators)
   - Extended (with separators)

   - Complete (fully specified class, no pieces missing)
   - Reduced precision (missing lower order items, e.g. year only)

   - Truncated (whether higher order items are implied, e.g. ---12
 specifies 12th day of current month and year)

   - Fractional (Time components may be represented as a fraction)

   - Expanded (The year may have additional digits and may be negative)

   - Ordinal (Days are expressed as Nth day of a year)
   - Week (Days are expressed as Nth day of Mth ISO week)

   - Timezone (Whether a timezone is allowed)


I would also like to be able to return additional information about
the format and the parsed components.  This would allow some
introspection when dealing with an unknown format.  For instance if I
know I may get a reduced format I may want to handle it differently in
my application, but I need to know if I am dealing with a year, decade
or century.

I could handle this by detecting how many items are passed as
arguments to parse_datetime() and handling it as a hash if I get more
than 1.  Similarly I can return different items if I am called in
array context...  However, if you call parse_datetime() and get a
DateTime::Duration object back that seems wrong.

I think the thing to do is make the parse_datetime() be a wrapper for
a sub with named parameters that restricts things to DateTime objects
only.  If you want the full power of the parser you need to call
parse_iso8601() or something.  Only parse_is08601 will support
returning multiple items using wantarray to detect the calling
context.

Or I perhaps you have to make an object and call parse_datetime()
through the object if you want to do anything complex.

I am leaving the formatting side out of the intial discussion, but it
has similar problems, for instance it needs to be able to take similar
format parameters to work out what kind of string to produce.

Does anyone have any suggestions.  I looked at the existing DT::F::
modules but they don't appear to have any similar interface problems.

Any suggestions would be appreciated.
Thanks,

-ben


Re: DateTime::Format::ISO8601 interface questions...

2003-07-03 Thread Ben Bennett
There is a lot to work out, but once the interface is clear it should
be very quick to implement.

Do you have any suggestions for what the interface should be or should
I just take a whack at it and see what people think?

  -ben

On Thu, Jul 03, 2003 at 11:43:03AM -0500, Dave Rolsky wrote:
 On Thu, 3 Jul 2003, Ben Bennett wrote:
 
 
  I am not sure what interface to use for the advanced features of the
  ISO8601 parser I wrote.  Right now I use a quick hack to make it work
  so I can test the parser.  It should be easy for me to change the
  interface to something sane, I just don't know what that should be.
 
  The basic usage should be:
  --
  my $iso = DateTime::Format::ISO8601
  my $dt = $iso-parse_datetime(20030211);
  --
 
  However, I want to be able to accept the following optional arguments:
   - The classes of formats to parse (Dates, Times, DateTimes,
 Durations, Recurrences)
   - The base DateTime object to use when things are implied (e.g. the
 date component when dealing with times, or any Truncated format,
 and some recurrences)  If not supplied this defaults to now().
   - The types to allow (each group is independent so you can have a
 Basic, Reduded, Week, Fractional, Expanded DateTime format):
 
 - Basic (no separators)
 - Extended (with separators)
 
 - Complete (fully specified class, no pieces missing)
 - Reduced precision (missing lower order items, e.g. year only)
 
 - Truncated (whether higher order items are implied, e.g. ---12
   specifies 12th day of current month and year)
 
 - Fractional (Time components may be represented as a fraction)
 
 - Expanded (The year may have additional digits and may be negative)
 
 - Ordinal (Days are expressed as Nth day of a year)
 - Week (Days are expressed as Nth day of Mth ISO week)
 
 - Timezone (Whether a timezone is allowed)
 
 Ok, so basically there's a lot left to work out for your parser.
 
 In that case, I think the ideal thing to do would be to release Joshua's
 parser now as DT::F::ISO8601, and then to continue work on yours, making
 it backwards compatible with Joshua's.
 
 Or in other words, please merge the damn things! ;)
 
 
 -dave
 
 /*===
 House Absolute Consulting
 www.houseabsolute.com
 ===*/


Re: DateTime::Format::ISO8601 namepsace

2003-07-03 Thread Ben Bennett

Ok, the new interface on mine is complete.

The only thing missing is POD and I will do that now.

The major problem with merging mine and Joshua's is that they take
totally different tacks for the implementation.

-ben

On Thu, Jul 03, 2003 at 08:56:39AM -1000, Joshua Hoblitt wrote:
  Joshua, why don't you check yours into CVS as DT::F::ISO8601, release it,
  and then you and Ben can merge in all the extra functionality from Ben's
  module.
 
 I wanted to dump it into CVS long ago but the namespace issue never cleared up.
 
 I'll try to get my laptop online tonight to make a CPAN release.  As I'm on the road 
 and without regular net access on my laptop I might wait a little bit before asking 
 SF to insert my tree, so I can keep working (this particular CVS limitation really 
 drives me nuts).
 
  My only rule for this is that there should only be one DT::F::ISO8601
  module, and that _eventually_, it should handle the complete spec.
 
 Not a problem.
 
 -J
 
 --


Re: DateTime::Format::ISO8601 namepsace

2003-07-03 Thread Ben Bennett
Sorry to reply to myself, but the new version of this thing is
available at:

http://www.limey.net/~fiji/perl/DateTime-Format-ISO8601-0.01.tar.gz

I think this is in roughly releaseable form.  I still have some TODO
items in the code (actually marked with XXX) but they are small items
that clean things up.

The POD is rough but reasonable.

The test suite is decent (it is all of the strings from the ISO
appendix and a few others I threw in).  I hope to add more, as well as
adding negative tests (i.e. strings I don't expect to be able to
parse, or ones that don't match the given type and class).

Remaining future development:
  - Add recurrence parsing (only issue is how to handle recurrences of
the form once a week for 3 weeks that has no date specified)
  - Add formatting of objects into ISO8601 strings (hopefully I can
use the recurrence stuff Flavio has been working on to write out a
recurrence).

Please advise.

   -ben



Re: DateTime::Format::ISO8601 namepsace

2003-07-03 Thread Ben Bennett
On Thu, Jul 03, 2003 at 12:01:33PM -1000, Joshua Hoblitt wrote:
  We could use a DT::Duration::Set module for things
  like once a week for 3 weeks
 
 That would be ideal.

Especially if (given a start or end date) you can turn it into a
DateTime::SpanSet


  How is that different from an ICal recurrence?

I am not sure.  I really haven't looked at the ICal stuff.

  Do we need a DT::Event::ISO8601 ?

 I've been thinking about this for a few days.  I don't think that DT::Event::ISO8601 
 would be useful on it's own.  DT::F::ISO8601 should just return a recurrence.

I agree (assuming you mean a DT::SpanSet).  The ISO8601 format is so
simple that I doubt you would want to create Sets that way
(DT::E::Recurrence is much more useful).

By the way, I have no idea why the recurrence syntax is at all useful
since there is no way to inducate spacing between the items.  I
suppose if the applications wanted they could ignore the length of the
recurrence and treat the starts as point events (or associate lengths
with them some other way).  But it is in the spec so...

-ben


Re: DateTime::Set::ICal

2003-07-03 Thread Ben Bennett
I assume that this only works for things created by ICal... 

Or can I make a set using DT::E::Recurrence and expect to be able to
serialize it out using DT::F::ICal?

Cool stuff though.

-ben

On Fri, Jul 04, 2003 at 02:00:34AM +, [EMAIL PROTECTED] wrote:
 Ok, I've got DateTime::Set::ICal implemented under
 DT:E:Recurrence. It's an 'internal use' class for
 recurrences that can be represented using ICal 
 statements.
 
 DT::Format::ICal can now format pretty complex sets
 as ICal statements:
 
 example from t/04recurrence.t:
 ..
 my $exclude = $union2-union(
 $ical-parse_datetime( '19980303T030303' )
)-complement(
 $ical-parse_datetime( '19980404T040404' )
);
 @str = $ical-format_recurrence( $exclude );
 
 # output:
 
 RRULE:FREQ=YEARLY;BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA 
 RRULE:FREQ=YEARLY;BYMONTH=2;BYDAY=SU,MO,TU,WE,TH,FR,SA 
 RDATE:19980303T030303
 EXDATE:19980404T040404
 
 format_recurrence() dies if it can't find a proper
 ICal representation for a set.
 
 - Flavio S. Glock
 


Re: ANNOUCE: DateTime::Format::DateManip

2003-07-01 Thread Ben Bennett
On Tue, Jul 01, 2003 at 09:04:14AM -1000, Joshua Hoblitt wrote:
 Looks good Ben.  The timezone stuff must have been fun. :)

Fun in which sense of the word :-)

 
 I ported a small piece of code (in production though) from Date::Manip to DT not 
 long ago.  I've been meaning to post the diffs and the benchmarks to the list.  I'll 
 do it as soon as I'm back on a fast connection.

Cool.
 
  Sometime I want to finish writing DateTime::Format::Complex that will
  grok complex English (although I want it to be localizable) date
  strings.  But that is still under consideration.
 
 Has DateTime::Format::ISO8601::(?:Complex) grown into this or is it a different 
 module?

No DT::F::ISO8601 (::?) is still a separate beast (which may get
called by DT::F::Complex).  ISO8601 parsing is pretty much done except
for recurrences...  I have some questions how to translate a
recurrence that has 5 instances 20 minutes apart but does not give a
start or end time.  I may just do as I do elsewhere and use an
optional user provided time (and fall back to now()).

We should get this name thing resolved so we can get both modules
committed and up on CPAN.  I don't care either way.

-ben


Re: ANNOUCE: DateTime::Format::DateManip

2003-07-01 Thread Ben Bennett
On Tue, Jul 01, 2003 at 07:36:48AM -0700, Hill, Ronald wrote:
 Yes, and so will Date::Calc (that is what I use) But I wanted to use only
 one
 Date module. It makes no sense to use say Date::Calc with DateTime.

I know you provided a code snippet below, but in general when using
Date::Calc do you use GMT or Local time when doing the operations?

If you mix the two, how do you keep track of which is which?

Do you use Date::Calc::Object?

I am trying to work out what the interface should be for a possible
DateTime::Format::DateCalc converter.  I think it is too complicated
to use the typical parse_datetime() style (because you need to tell
the sub whether it is in GMT or local time).  Also it would be nice to
have a sub that could take the date and time parts and put them
together into a DT and vice versa.

Anyway, any suggestions would be appreciated.

Thanks,

  -ben


Re: DateTime::Duration nits...

2003-06-30 Thread Ben Bennett
On Mon, Jun 30, 2003 at 12:20:43PM -0500, Dave Rolsky wrote:
   2) Having a way to construct this directly would be nice being able
  to make a duration that you can not directly construct seems odd.
 
 Well, maybe.  Right now the constructor is really simple, which is good.
 More functionality is nice, but so is simplicity.

Ok, playing with this a bit more (using DateTime 0.13) makes me confused:

--
my $d = DateTime::Duration-new(hours = -3, minutes = 57, seconds = 2);
--
Gives 'minutes' = -123, 'seconds' = -2.

--
my $d = DateTime::Duration-new(hours = 3, minutes = -57, seconds = 2);
--
Gives 'minutes' = -123, 'seconds' = -2.

BUT

--
my $d = DateTime::Duration-new(hours = -3, minutes = -57, seconds = 2);
--
Gives 'minutes' = -237, 'seconds' = -2.

AND

--
my $d = DateTime::Duration-new(hours = 3, minutes = 57, seconds = -2);
--
Gives 'minutes' = -237, 'seconds' = -2.

I am totally mystified.  I read If any of the numbers are negative,
the entire duration is negative. as indicating that the individual
signs don't matter.

I think the error is on DT::Duration line 52:
  $self-{minutes} = abs( ( $p{hours} * 60 ) + $p{minutes}  ) * $self-{sign}; 
Which should perhaps be:
  $self-{minutes} = ( abs( $p{hours} * 60 ) + abs( $p{minutes} ) ) * $self-{sign}; 

-ben


ANNOUCE: DateTime::Format::DateManip

2003-06-30 Thread Ben Bennett

I needed to convert between Date::Manip and DateTime so I wrote a
module to convert the date and duration formats (recurrences may
follow if there is demand, there are some nasty wrinkles though).

Get it from http://www.limey.net/~fiji/perl/

If people see no major problems with this module I will add it to CVS
and CPAN.  I also want to update the FAQ with a section on how to
convert between different timezone modules, since most of the other
modules use epochs that is easy to handle.

I wanted to write one to convert Date::Calc::Object as well, but
timezones really get ugly there.  Since the TZ info is not kept with
the object the user would have to tell us whether it was in local or
GMT time when converting in both directions.  I am still thinking
about how to handle the interface in a sane manner.

-ben


Re: DT::F::Builder multiple identical lengths

2003-06-25 Thread Ben Bennett
I know you can mix them, but I would prefer to match completely since
as I said there is a decent speed win.

The fact that multiple formats can match is irrelevant here (that is
dealt with when filtering by type).  It might be useful to someone to
be able to get the parts of the given string back in a hash so that
they can see what pieces were not specified (in the case of a reduced
format).  Also in the case of Time only formats, it is a bit of a hack
to massage them into a DateTime, so it may be more useful to get the
parsed pieces back to use in another way.

Also the recurrence format Rn/PnYnMnDTnHnMnS is tricky since the start
date and time are not specified.  I plan on handling that the same way
that I do with the time components and using the date the user passed
in or DT-now() if none was specified...  However, I may want to get
at the parts of the recurrence from the calling code.

-ben

On Wed, Jun 25, 2003 at 07:04:05AM -1000, Joshua Hoblitt wrote:
 On Wed, 25 Jun 2003, Ben Bennett wrote:
 
  All true... but my benchmarking as I wrote my ISO8601 showed that the
  speed gained by pre-filtering by length to reduce the number of
  regexps that need to be tried is substantial.
 
 You can mix length with no-length specrefs.
 
  The other thing that my ISO8601 parser does is (optionally) return the
  format specification and pieces of the time string (because it is not
  always possible to cleanly map an ISO8601 string into a DT, but the
  module tries its best).  Is there a way to easily do that with Builder
  that I haven't spotted yet?
 
 Theres only 6 strings that can match either dates or time.
 
 hhmmss
 hhmm
 hh
 -mmss
 -mm
 --ss
 
 -J
 
 --


Re: Problems with DateTime::TimeZone-short_name_for_datetime()

2003-06-25 Thread Ben Bennett
Oh.  Duh.  I took the line This class has the following methods to
mean that it was a class method not an object method.  Dunno why I
read it like that, everything is pretty clearly intended to be called
through an object.

Anyway, DateTime's time_zone_short_name method was actually what I
should have been using since I don't have a TZ object the TZ should be
able to tell me it's short name...

 Thanks,

 -ben

On Wed, Jun 25, 2003 at 01:50:39PM -0500, Dave Rolsky wrote:
 On Wed, 25 Jun 2003, Ben Bennett wrote:
 
  my $short = DateTime::TimeZone-short_name_for_datetime($dt);
 
 This is an object method, not a class method.
 
  On a related note, while trying to chase this problem I noticed that
  DT::TZ-span_for_datetime() compares $type to UTC to determine $end,
  but all of the callers are passing in utc.
 
 That's a bug.  Now I just need to figure out how to test it.
 
 
 -dave
 
 /*===
 House Absolute Consulting
 www.houseabsolute.com
 ===*/


Re: What's up with DT::TZ::Alias?

2003-06-23 Thread Ben Bennett
On Mon, Jun 23, 2003 at 12:34:13AM -0500, Dave Rolsky wrote:
 
 Also, I'm not entirely against the idea of folding all the alias stuff
 into the main DT::TZ module.  It doesn't seem like an entirely wack idea,
 though I'd be glad to hear why I'm wrong ;)

I think this is the right thing to do.

A little voice has been saying that ever since I saw that Alias was
reaching into the TZ aliases directly.

-ben


Re: What's up with DT::TZ::Alias?

2003-06-23 Thread Ben Bennett
Yeah, I know.  That is what rang the initial warning bell.

Frankly the functionality provided by Alias seems to be vital to the
TZ package anyway.  (Kudos for writing it).

   -ben

On Mon, Jun 23, 2003 at 10:11:02AM -1000, Joshua Hoblitt wrote:
  A little voice has been saying that ever since I saw that Alias was
  reaching into the TZ aliases directly.
 
 There's a warning about this in the pod. :)
 
 -J
 
 --


Re: Standalone Times?

2003-06-22 Thread Ben Bennett
On Sun, Jun 22, 2003 at 04:47:42AM +0200, Eugene van der Pijll wrote:
 
 If YY really is the century, you should probably return Jan 1st, 1901
 when given 20...

The example given in the spec says that given 12 April 1985 YY gives
19.  So they are being a little loose with the word century...

-ben


Re: Business Dates

2003-06-22 Thread Ben Bennett
I used to live in Saudi Arabia and the weekend was on Thursday and
Friday (I don't know what calendar businesses used but I will ask my
father).

-ben

On Sun, Jun 22, 2003 at 01:37:24AM -0500, Dave Rolsky wrote:
 On Sun, 22 Jun 2003, Eugene van der Pijll wrote:
 
  Businesses in Israel, Iran and in the Arab world probably use a business
  calendar based on the Hebrew, Jalali and Hijira calendars. It would be
  nice if one module could be used for the Gregorian calendar and for
  these three calendars.
 
 Actually, I'd guess they use a business calendar where the work week is
 still Monday - Friday (or through Saturday), but where _holidays_ are
 determined by a given religion, which in turn uses a different calendar.
 
 But nonetheless, days of the week and days of the month are still going to
 be Gregorian.  I doubt that businesses in Israel refer to dates by the
 Hebrew calendar.
 
 
 -dave
 
 /*===
 House Absolute Consulting
 www.houseabsolute.com
 ===*/


Re: www docs

2003-06-22 Thread Ben Bennett
Check out Dave's work on the POD to HTML stuff for the FAQ for a
start...

-ben

On Sun, Jun 22, 2003 at 06:41:16PM -0500, Dave Rolsky wrote:
 On Sun, 22 Jun 2003, Dave Rolsky wrote:
 
  On Sun, 22 Jun 2003, Joshua Hoblitt wrote:
 
   Should I add the namespaces doc to web/htdocs/developer/?
 
  Sure, please do.
 
 BTW, you should use Pod::Simple::HTML for the conversion, not pod2html
 that comes with Perl.  The latter produces really icky output that needs
 _lots_ of editing to clean up.  The former is much easier to convert into
 a Mason component for the DT site.
 
 
 -dave
 
 /*===
 House Absolute Consulting
 www.houseabsolute.com
 ===*/


Re: Getting different results from DateTime and Manip for epoch time

2003-06-22 Thread Ben Bennett
Fantastic!  Thank you for the summary, I will add it to the FAQ (with
appropriate attribution of course).

-ben

On Sun, Jun 22, 2003 at 10:36:02PM +, [EMAIL PROTECTED] wrote:
 Thanks Eugene.
 
 I'll try to rephrase this, because it 
 would be good to have it in the FAQ. 
 If somebody can explain it better, or
 more correctly, please help me!
 
 What's up with GMT, TAI, UTC, and UT1?
 
 Before 1972, the international time reference
 was GMT. In GMT, all days have the same number
 of seconds. A day starts at midnight and has
 86400 seconds.
 
 TAI is another time measuring system, in
 which seconds depend on atomic time only,
 instead of the Sun-Earth position.
 TAI days have 86400 seconds, and it's
 origin is in 1958 January 1.
 
 Parallel with those, there exists UT1, which
 is the astronomical time. 
 UT1 depends only on Sun-Earth position.
 UT1 - TAI is some fractional seconds.
 
 In 1972 UTC was introduced, in order to
 approximate international time to 
 astronomical time.
 Now, whenever the difference between UTC and
 UT1 is big enough, a leap second is introduced.
 UTC is synchronized to TAI, which means that
 UTC - TAI is an integer number of seconds.
 UTC - UT1 is some fractional seconds.
 
  [EMAIL PROTECTED] schreef:
   
 http://hpiers.obspm.fr/eop-pc/earthor/utc/leapsecond.
   html
   
   ... Since the system was introduced in 1972, 
   
   The table starts in 1972. Before that, GMT was
   in use - not UT1!
  
  Not true. UT1 existed at least since 1958. In that 
 year, TAI (atomic
  time) was synchronized with UT1.
  
  UT1 is based on the observed length of the day 
 (corrected for some
  large scale effects like the movement of the 
 poles). As it is
  observation based, it is not a good timescale to 
 base civil time on.
  UT was used for that. Periodically the 
 correspondence of UT and UT1 was
  checked, and UT was corrected by changing the 
 length of the day, and by
  adding a small time adjustment to account for the 
 accumulated
  difference.
  
  Civil time was based on UT: GMT was UT+, MET 
 was UT+0100, EST was
  UT-0500 IIRC (as long as you're not in Australia).
  
  So the role of UT/GMT was taken over by UTC, not by 
 UT1.
  
  Eugene
  
 


Re: ISO 8601 is eeeevil!

2003-06-20 Thread Ben Bennett
I will try to have something usable by tomorrow...  I made some decent
progress last night.

   -ben

On Fri, Jun 20, 2003 at 01:08:13PM +1000, Iain Truskett wrote:
 * Ben Bennett ([EMAIL PROTECTED]) [20 Jun 2003 12:59]:
  On Wed, Jun 18, 2003 at 06:42:06PM -1000, Joshua Hoblitt wrote: [...]
   When I started writing DateTime::Format::ISO8601 I was using the
   ordering method.  Although I think it maybe necessary to to use both
   1 and 2.  Someday I may finish this module - what name are you
   planning on using?
 
  I was thinking about DateTime::Format::ISO8601... unless you have laid
  claim to it.
 
  I don't know if I will manage to finish this thing, it is a bit of a
  monster.
 
 Perhaps one of you should add it to the CVS server as-is and both work
 on it?
 
 
 cheers,
 -- 
 Iain.


Re: RFC: Fiscal Dates

2003-06-20 Thread Ben Bennett
There was a recent disussion about what a business date module should
be able to do that might be interesting if you want to make this
module do other business calculations...

   -ben

On Fri, Jun 20, 2003 at 08:00:17AM -0400, Jesse Shy wrote:
 
 I currently have a subclassed module I created for an application here at
 work, called Date::Calc::Fiscal. The interface takes 2 dates, the fiscal
 start date and the date your interested in - returning either the day
 number or week number of the fiscal year. So if your fiscal start day is
 Feb 1, then Feb 1 is day 1 of week 1, or iso I guess is week 0 and Jan 31
 is day 365 or 366 depending. We use this in a web app to show individual
 customers their invoicing by periods that match their internal accounting
 practices.
 
 After some thought, I realized that this was simply the application and
 that the function is realy a numerical day adjustment to either the
 gregorian or pataphysical calendars, depending on whether you have 12 or
 13 periods in calender ( fiscal instrument ).
 
 So first I am wondering about namespace. I can not think of another place
 where this is needed other than finacial apps, so I was thinking
 DateTime::Fiscal, but as I said earlier, that is really the application
 not the function however, if this is the only application than this name
 fits.
 
 Currently I only have 2 methods, day_of_fiscal_year and
 week_of_fiscal_year. I would eventually like to use DateTime::Set, ::Span
 ::SetSpan along with calendaring to create fiscal calendars showing end of
 period dates, etc...
 
 I would love some feedback on these thoughts or anything related to this
 that I may not have thought of. Thanks.


Re: RFC: Fiscal Dates

2003-06-20 Thread Ben Bennett
No, you aren't blind, the archives at
'http://archive.develooper.com/[EMAIL PROTECTED]/' appear to be
missing a lot of stuff.  Does anyone know what is going on?

Try using 'http://nntp.x.perl.org/group/perl.datetime' for the moment.
The particular thread starts at:
http://nntp.x.perl.org/group/perl.datetime/2714
But there is no threading support on that server unless you use the
news interface (and the thread goes on for a while).

   -ben

On Fri, Jun 20, 2003 at 08:30:52AM -0400, Jesse Shy wrote:
 I apologize if I am blind, I looked in the archives and did not see the
 thread for business calculations. Was this the topic or did it start from
 something else. Thanks.
 
 


Re: Business Dates

2003-06-20 Thread Ben Bennett

I am still in the thinking about this phase...

I am not sure what your mean by 'logical progression' etc.  Do you
mean the current state or the ideal future state that the frightening
email thread alludes to?

I was under the impression that the Pataphysical calendar was
basically a fictional one that parodies the French Catholic calendar
(http://user.icx.net/~richmond/rsr/pataphysique/pataphysique.html).
Are you suggesting that it is useful for business calculations?

Your point about the variable fiscal year start dates is a good one
though.  We definitely need to take that into account.

  -ben

On Fri, Jun 20, 2003 at 11:50:20AM -0400, Jesse Shy wrote:
 I read the thread as you suggested Ben; now I am veryh afraid. Is anyone
 working on any of this? I am interested in not only what I descibed
 earlier, but also the stuff concerning contracts and billing periods...
 and later the work rules stuff. Are there any lists or diagrams that show
 what can be built on top of what exist and a logical progression how to
 get to some of the more speciallized aspects?
 
 I think what I proposed earlier may be a good start and could have a
 method like
 
   ::use_calendar( 'Gregorian' ) or Pataphysical etc...
 
 Then do day week calculations to come up with that type of calendar
 adjusted. A Gregorian calendar still has the same number of weeks and days
 only with the begining and ending dates realigned.
 
 I could be wrong though.


Re: [rfc] DateTime::Util

2003-06-20 Thread Ben Bennett
Is this for taking an ISO week number and day of week and getting a
month, day and year back?

Dave, would it be possible to have a DT constructor for this?  There
is an accessor (week()) that does the reverse...  For the ISO8601
module it would be nice to have this, although it is easy enough to do
by hand.

-ben

On Fri, Jun 20, 2003 at 12:11:22AM -1000, Joshua Hoblitt wrote:
 As I'm thinking about normalizing week + day numbers to month + day numbers I'm 
 wondering if there shouldn't be a module for all such common (to DT modules) 
 conversion functions?  Comments?
 
 -J
 
 --


Rough ISO8601 parser ready...

2003-06-20 Thread Ben Bennett
I have made my rough ISO8601 parser available at:
  http://www.limey.net/~fiji/perl/DateTime-Format-ISO8601-0.01.tar.gz

Since this is a rough first release there are huge things wrong with
it.  An incomplete list is:
 - No documentation
 - Module name not settled yet
 - Only parses Dates (no times, recurrences or durations... yet)
 - Code is littered with XXX indicating areas of further thought
 - Code is littered with debug stuff
 - Code should be much cleaner before release
 - The interface is nowhere near done
 - Needs more tests (and tests of failure)
 - Error handling doesn't exist

What it does do at the moment:
- Parses any valid ISO8601 date
- Allows you to pick which format categories to apply (but the
  interface is awful!)
- Does selection by variable length (8+ characters)
- Reasonably efficient algorithm for picking which formats match
  the user's categories
- Test suite works now (and is passed completely)

If you want to play with this either check out the test suite, or use
the following line as a basis:

PERL5LIB=lib perl -MDateTime::Format::ISO8601 -e 'print 
DateTime::Format::ISO8601-parse_datetime(shift, shift)-datetime(), \n' 2003W011


The optional second argument is the formats to use.  The valid formats are:
  C: Complete (fully specified date)
  R: Recuced Precision (less significant items are dropped)
  T: Truncated (current items implied)
  B: Basic (no separators)
  E: Extended (with separators)
  X: Expanded (extra years)
  O: Ordinal date (day count from year)
  W: Week date (day count from year)

The default is to try all of them (XWOTCREB).

You must always pass in E or B and C or R since each format has those types.

So if you only wanted to use Complete Basic items, pass in CB.

 -ben


Re: ISO 8601 is eeeevil!

2003-06-19 Thread Ben Bennett
Well that was always my intention.  I plan to allow the caller to
specify what exact rules to use since the spec basically allows very
little unless the parties agree.

However, I think that the default format (if nothing was specified)
should allow for parsing of common ISO8601 formats.

This need not be settled yet, I will try to get the module out so
people can better see what I have in mind and critique working code.

 -ben

On Thu, Jun 19, 2003 at 11:35:58AM -0700, Bruce Van Allen wrote:
 An interesting challenge here might be to devise a way to allow DateTime to exploit 
 the full range of ISO 8601 formats, in cases where the user knows that the 
 appropriate agreements exist among the parties.
 
 Perhaps a DT::F::ISO8601 parameter like
accept = ['DDD'],
 could be used, evoking the necessary routines to parse  format. (I put this in the 
 form of an array ref to handle multiple accepts.)
 
 Just a thought.
 
  - Bruce


Re: ISO 8601 is eeeevil!

2003-06-19 Thread Ben Bennett
On Wed, Jun 18, 2003 at 06:42:06PM -1000, Joshua Hoblitt wrote:
[...]
 
 When I started writing DateTime::Format::ISO8601 I was using the ordering method.  
 Although I think it maybe necessary to to use both 1 and 2.  Someday I may finish 
 this module - what name are you planning on using?

I was thinking about DateTime::Format::ISO8601... unless you have laid
claim to it.

I don't know if I will manage to finish this thing, it is a bit of a
monster.

-ben


Re: utc_rc_values nanosecond support

2003-06-18 Thread Ben Bennett
On Wed, Jun 18, 2003 at 10:14:32AM -1000, Joshua Hoblitt wrote:
 Hi Dave,
 
 Two questions:
 
 1) When is fractional second support going to be dropped?

Already dropped in CVS.  So whenever the next release happens...


I agree that we need to fix the ns support when switching calendars.

   -ben


ISO 8601 is eeeevil!

2003-06-18 Thread Ben Bennett

Ok.  So ISO8601:2000 defines all sorts of things, some of which are
impossible to distinguish from one another without outside
information:

+yMMDD  Extended complete year
+yDDD   Extended ordinal day in year
-YYMM   Year and month in implied century
-DDDOrdinal day in implied year
-YY Year in implied century
+y  Extended year
+yYYExcended century

Notation:
 -: - Character
 Y,M,D: Year, month, day digit respectively
 +: + or - characters
 

The root of the collisions is the arbitrary number of extended digits
(which may be 0, so you could have -0101, now is that the year 102
BC, or January in 2001?  The extended formats also collide internally,
i.e. what is the date +1985?  Is it a century or a year?


The choices for resolving this are to:
  1) Never allow an extended representation (even for +s which can't
 collide externally) unless the user tells us to use it and
 specifies the digits
  2) Use the ordering above to break ties

I am leaning towards choice 2 for this, but things are not completely
dire since I plan to allow the user of the module to pick which
categories of formats to allow (and to specify how many digits are in
an extended date).


There are also collisions with time strings, but those are resolvable
with the following rules (stopping with the first rule that fits):
  - It is what the user says it is
  - If there is a T prefix
  - If there is a TZ (Z or offset)
  - If there are : separators
  - Otherwise assume it is a date

  -ben


Re: date normalization

2003-06-17 Thread Ben Bennett
I have actually been thinking about that a bit...

The way it is shaping up is that it will be a generic DT::SpanSet
wandering thing... So given a SpanSet (or Set, or Span) it will be
able to do operations within its context (i.e. date arithmetic,
etc.).

DT::E::BusinessDay would simply be a superclass of this (as yet
unnamed) base class that would define some business specific functions
(and possibly aliases for some methods).

 -ben

On Mon, Jun 16, 2003 at 09:56:11PM -1000, Joshua Hoblitt wrote:
  Hang on a second .. isn't this all a part of DateTime::Event::BusinessDay?
 
 Maybe BusinessDay doesn't describe the functionality all that well then. :)


Re: [announce] DateTime::TimeZone::Alias 0.01 (fwd)

2003-06-17 Thread Ben Bennett

On Tue, Jun 17, 2003 at 09:52:46AM -1000, Joshua Hoblitt wrote:

 Btw - US/Eastern is defined as an alias unless you removed it earler in the program.
 

Yeah, that is why I have to jump through more hoops in my example.

 How would an add method that returns silently if an alias is already defined tell if 
 an alias has been redefined somewhere else?

It _only_ returns silently if the current definition matches the
real timezone of the requested definition:
--
my $dta = DateTime::TimeZone::Alias;

$dta-remove(EST);# Start with a clean slate
$dta-add(EST = US/Eastern);   # Succeeds
$dta-add(EST = US/Eastern);   # Succeeds
$dta-add(EST = America/New_York); # Succeeds
$dta-add(EST = America/Chicago);  # Fails
--

 If you mean;
[...]
 Then say it.

Neither are what I mean.  Hopefully my example above clarifies things...

 -ben


Re: [announce] DateTime::TimeZone::Alias 0.01 (fwd)

2003-06-17 Thread Ben Bennett
Ok.  It is your module so this is your call.

I disagree, but that is ok.  This should end the thread.

   -ben

On Tue, Jun 17, 2003 at 01:26:43PM -1000, Joshua Hoblitt wrote:
  my $dta = DateTime::TimeZone::Alias;
 
  $dta-remove(EST);# Start with a clean slate
  $dta-add(EST = US/Eastern);   # Succeeds
  $dta-add(EST = US/Eastern);   # Succeeds
  $dta-add(EST = America/New_York); # Succeeds
  $dta-add(EST = America/Chicago);  # Fails
  --
 
 I know what your asking for but I don't like the behavior.  This would be 
 non-intuitive for most users, including me.  Calling add more then once to perform 
 the same action is a logic error.
 
 Cheers,
 
 -J
 
 --


Re: What should a business module implement?

2003-06-17 Thread Ben Bennett
Is that a generic business calculation or just an application of sets?

I think the latter.  You can just make a set representing the
intersection of mondays (or weekdays) and Dec. 31sts.  Then iterate
over it (using the restricted time range) to find the solution.

--
use strict;
use DateTime;
use DateTime::Event::Recurrence;

my $dec32   = DateTime::Event::Recurrence-yearly
(months = 12, days = 31);
my $mondays = DateTime::Event::Recurrence-weekly
(days   = 1);
my $s = $dec32-intersection($mondays);

my $i = $s-iterator(start = DateTime-new(year = 2000),
 end   = DateTime-new(year = 2008));
while (my $d = $i-next) {
printf %s - %s\n, $d-day_name(), $d-datetime;
}
--

Prints:
--
Monday - 2001-12-31T00:00:00
Monday - 2007-12-31T00:00:00
--

  -ben

On Tue, Jun 17, 2003 at 01:39:00PM -1000, Joshua Hoblitt wrote:
 What if I wanted to know inside a range of years which had a December 31st that was 
 on a Monday (or on a weekday)?
 
 -J
 
 --


Re: date normalization

2003-06-16 Thread Ben Bennett
Isn't that simply:

my $safe_span = ...;# Whatever you need
my dt = DateTime-new(...);
croak Bad date range if $safe_span-contains($dt);

In fact you may want the span to be a spanset to accomodate more fine
grained controls.  Is this useful enough to merit a class?  I dunno.

As a minor note, it might be nice to be able to chain the Wrappers,
but I have no idea what syntax one would use.

-ben

On Sun, Jun 15, 2003 at 04:15:49PM -1000, Joshua Hoblitt wrote:
[snip]
 
 However - I was thinking of a validator that could be configured with input ranges 
 for each parameter.
 
 Example:
 
 $start = DateTime-new( year = 1939 );
 $end   = DateTime-new( year = 1945 );
 $year_span = DateTime::Span-from_datetimes( start = $start, end = $end );
 
 my $dtvdator = DateTime::Wrapper::Validator-watch( year = $year_span );
 
 # creates a DT object
 my $dt = $dtvdator-new( year = 1944 );
 
 # throws an exception
 my $dt = $dtvdator-new( year = 1938 );
 
 I'm kinda fuzzy on watch the syntax (or what the method name should be).
 
 -J
 
 --
 


Re: milli/micro seconds

2003-06-16 Thread Ben Bennett
Dave already said that he was open to adding a flag to control the
overflow behavior if anyone could provide a valid reason for needing
it.

It sounds like you have a good reason, so post it and see if he will
add the flag.

-ben

On Mon, Jun 16, 2003 at 08:43:50AM -1000, Joshua Hoblitt wrote:
 Hi Rick,
 
  Cool idea .. and I'll add DateTime::Wrapper::AllowThingsToOverflow
  (or something shorter) that allows you to construct with overflowing
  parameters (like 75 seconds, 124 minutes, 34 hours, 98 days and 16
  months)
 
 Are you still going to do this?  I already want to subclass it for something. :)
 
 -J
 
 --


Re: date normalization

2003-06-16 Thread Ben Bennett
Ok, lets say that you want only working hours as legal times, so
9-12,1-5, M-F from July 1st to July 17th, 2003.

Most of the code below is building the ranges... I think youy would
have to do that anyway.  The real bit that the module would do is the
intersection stuff, and that is a couple of lines.

I have included some test code to print out the legal ranges.

   -ben

--
#!/usr/local/bin/perl -w

use strict;
use DateTime;
use DateTime::Span;
use DateTime::SpanSet;
use DateTime::Event::Recurrence;
use Carp;

# Make a set representing mondays to fridays
my $working_days = 
DateTime::SpanSet-from_sets
(start_set = DateTime::Event::Recurrence-weekly(days = 1),
 end_set   = DateTime::Event::Recurrence-weekly(days = 6),
 );

# Make the working hour restriction
my $working_hours =
DateTime::SpanSet-from_sets
(start_set = DateTime::Event::Recurrence-daily(hours = [9,  1]),
 end_set   = DateTime::Event::Recurrence-daily(hours = [12, 5]),
 );

# Make the date range
my $date_range = DateTime::Span-from_datetimes
(start = DateTime-new(year = 2003, month = 7, day = 1),
 end   = DateTime-new(year = 2003, month = 7, day = 18)); # 1-17 inclusive

# Build the spanset of legal times
my $legal = $working_days-intersection($working_hours)
 -intersection($date_range);


## Test code
my $iter = $legal-iterator();
while ( my $dt = $iter-next ) {   # $dt is a DateTime::Span
printf %s to %s\n, $dt-start-datetime, $dt-end-time;
};
##

# Now test the date
my $dt = DateTime-new(year = 2003); # Your date here
croak Bad date range unless $legal-contains($dt);
--

On Mon, Jun 16, 2003 at 08:42:14AM -1000, Joshua Hoblitt wrote:
  my $safe_span = ...;# Whatever you need
  my dt = DateTime-new(...);
  croak Bad date range if $safe_span-contains($dt);
 
 In my [poor] example.  But what if you only wanted to only accept time values from 
 11:00-18:00 across a span?
 
  In fact you may want the span to be a spanset to accomodate more fine
  grained controls.  Is this useful enough to merit a class?  I dunno.
 
 I think it could be useful - I'm just not that sure about the syntax.
 
 Cheers,
 
 -J
 
 --


Re: date normalization

2003-06-16 Thread Ben Bennett
Ah! nice.  I don't fully understand DT:E:Recurrence yet...

Slight correction to both scripts:
  The hours should be 13 and 17 instead of 1 and 5 (damn PM...).

Then yours should be (otherwise it picks up Saturdays too):
 days = [1..5]

Which is more clear than mine anyway...

  -ben

On Mon, Jun 16, 2003 at 11:49:16PM +, [EMAIL PROTECTED] wrote:
 Joshua Hoblitt said:
  There must be a way to express the same semantic
  meaning with fewer lines of code
 
 A slightly smaller version - specify days and hours
 in the same constructor.
 
 - Flavio S. Glock
 
 ---
 #!/usr/local/bin/perl -w
 
 use strict;
 use DateTime;
 use DateTime::Span;
 use DateTime::SpanSet;
 use DateTime::Event::Recurrence;
 use Carp;
 
 # Make a set representing mondays to fridays, with
 # the working hour restriction
 my $working_days = 
 DateTime::SpanSet-from_sets
   (start_set = DateTime::Event::Recurrence- 
weekly( days = [1..6],hours = [9,  1]),
end_set = DateTime::Event::Recurrence- 
weekly( days = [1..6],hours = [12, 5]),
   );
 
 # Make the date range
 my $date_range = DateTime::Span-from_datetimes
 (start = DateTime-new(
 year = 2003, month = 7, day = 1),
  end   = DateTime-new(
 year = 2003, month = 7, day = 18)); 
 
 # Build the spanset of legal times
 my $legal = $working_days-intersection($date_range);
 
 ## Test code
 my $iter = $legal-iterator();
 while ( my $dt = $iter-next ) {   
 printf %s to %s\n, 
$dt-start-datetime,
$dt-end-time;
 };
 ##
 
 # Now test the date
 my $dt = DateTime-new(year = 2003);
 croak Bad date range unless $legal-contains($dt);
 


Re: [announce] DateTime::TimeZone::Alias 0.01

2003-06-16 Thread Ben Bennett
I think DateTime::TimeZone::Alias 0.03 is really looking good.  The
docs are excellent (small patch to fix typos included below).

I really like the new is_X subs, although in the case of the
is_alias() would it make sense to return the target of the alias?

i.e. If I have aliased EST to America/New_York, could it return
America/New_York rather than 1?  Both are true so it should be
equivalent, but being able to get the mapping seems useful.  Although
if I had EST = US/Eastern, then what should it return?  I argue that
it should still return America/New_York since that is the base time
zone.

Finally I still think that not throwing an error if add()ing a
duplicate definition makes sense (although I agree that croak()ing is
the right thing to do).  I would like to be able to do:

--
my $dta = DateTime::TimeZone::Alias;
$dta-add(EST = US/Eastern);
...
$dta-add(EST = US/Eastern); # This should be OK
$dta-add(EST = US/Central); # This should croak
--

(In fact an add(America/New_York should also not die).  My theory
being that people may have a sanity check in a few places to make sure
the right TZ mappings are defined.  For instance at work we use Mason
running in mod_perl under Apache, so the same environment persists
across different pages.  If one page does the add() I wouldn't want a
subsequent page to have to jump through hoops to check the definition
of the alias is correct if doing an equivalent add()...  I don't think
we lose anything by allowing a subsequent add() to silently be skipped
if it is the same.

One last thing, I just realized that the subs expect to be called as
class methods.  This is fine unless you want to alias them into your
package (or accidentally call them like DateTime::TimeZone::Alias::add()).  
The following fails:
--
use DateTime::TimeZone::Alias;
*set_tz = \DateTime::TimeZone::Alias::set;
set_tz(EST = US/Eastern);
--

I don't know if it is exactly an error, but it is a little annoying.
You could fix it by checking the argument count but that doesn't
handle remove()... also it will fail if someone wants to superclass
this class since add calls set through the class.  I have no idea if
there is a general solution to this problem, someone must have hit it
before though.

   Cool stuff, Nice work!

-ben

The POD diff:
--
--- Alias.pod.orig  2003-06-16 21:52:23.0 -0400
+++ Alias.pod   2003-06-16 21:52:59.0 -0400
@@ -48,7 +48,7 @@
 Accepts a hash representing an alias and the timezone it should map too.
 If an invalid timezone value is passed an exception is thrown.
 It is possible to create an alias to another alias.  This method will
-redefined an existing alias or add a new alias that overrides an existing
+redefine an existing alias or add a new alias that overrides an existing
 timezone.
  
 =item * add( alias = timezone, ... )
@@ -56,7 +56,7 @@
 Accepts a hash representing an alias and the timezone it should map too.
 If an invalid timezone value is passed an exception is thrown.
 It is possible to create an alias to another alias.
-This method will _not_ redefined an existing alias or allow you remap a
+This method will _not_ redefine an existing alias or allow you remap a
 timezone.  For redefinitions see the Cset method.
  
 =item * remove( alias, ... )


Re: date normalization

2003-06-15 Thread Ben Bennett
On Mon, Jun 16, 2003 at 12:01:21PM +1000, Iain Truskett wrote:

 That version isn't on CPAN yet. To be honest, I'd really
 like the validation to be optional. While some people have
 more use for validation rather than normalization, others
 (like me) are the opposite =)

I half agree.  Initially I thought that it should be optional and said
so on the list.  Dave replied saying that he wouldn't make it so
unless anyone had an example of why it needed to be optional.

So far I haven't come up with a reasonable one.  If you have a real
case mail it to the list.

 -ben


Re: Nanoseconds in the FAQ.

2003-06-12 Thread Ben Bennett
Oops, thanks.  Revised version:

=head3 How small an increment of time can I represent?

ADateTime can represent nanoseconds.  You can create obects with
that resolution using the Cnanosecond parameter to Cnew or Cset
and there is a corresponding Cnanosecond accessor.  For these you
give an integer count of the nanoseconds.

A millisecond is a thousandth of a second (10^-3 or 0.001).  The
abbreviation is Ims.
A microsecond is a millionth of a second (10^-6 or 0.01).  The
abbreviation is Ius (or more properly IEmicros).
A nanosecond is a billionth (US) of a second (10^-9 or 0.1).
The abbreviation is Ins.

=for example begin

  # The ns part is 0.00230 below
  my $dt_ns = DateTime-new(year = 2003, month = 3,   day = 1,
hour = 6,minute = 55, second = 23,
nanosecond = 230);
  print ns: , $dt_ns-nanosecond, \n;  # Prints: ns: 230\n

  # Assuming we got milliseconds as an argument
  my $ms = 42;
  my $dt_ms = DateTime-new(year = 2003, month = 3,   day = 1,
hour = 6,minute = 55, second = 23,
nanosecond = $ms * 1_000_000);
  print ms: , $dt_ms-nanosecond, \n;  # Prints: ns: 4200\n



=for example end

=for example_testing
  is($_STDOUT_, ns: 230\nns: 4200\n, Nanoseconds);



-ben

On Wed, Jun 11, 2003 at 10:05:02PM -0700, Bruce Van Allen wrote:
 
 On Wednesday, June 11, 2003, at 07:08  PM, Ben Bennett wrote:
 I added a section on nanoseconds:
 The raw POD is below.
 
 
 =head3 How small an increment of time can I represent?
 
 ADateTime can represent nanoseconds.  You can create obects with
 
 =for example begin
 
   # The ns part is 0.00230 below
   my $dt_ns = DateTime-new(year = 2003, month = 3,   day = 1,
 hour = 6,minute = 55, second = 23,
  nanosecond = 230);
   print ns: , $dt_ns-nanosecond, \n;  # Prints: ns: 230\n
 
   # Assuming we got microseconds as an argument
   ^
 I think you meant:milli
 
   my $ms = 42;
   my $dt_ms = DateTime-new(year = 2003, month = 3,   day = 1,
 hour = 6,minute = 55, second = 23,
  nanosecond = $ms * 1_000_000);
   print ms: , $dt_ms-nanosecond, \n;  # Prints: ms: 4200\n
^^
 That number is in nanoseconds (42 milliseconds is 42,000,000 
 nanoseconds); does it make sense to label it 'ms' in the test output?
 
   - Bruce
 
 __bruce__van_allen__santa_cruz__ca__


Re: Nanoseconds in the FAQ.

2003-06-12 Thread Ben Bennett
Please ignore the last one... I biffed it too.  Below is the corrected
POD.

  -ben

=head3 How small an increment of time can I represent?

ADateTime can represent nanoseconds.  You can create obects with
that resolution using the Cnanosecond parameter to Cnew or Cset
and there is a corresponding Cnanosecond accessor.  For these you
give an integer count of the nanoseconds.

A millisecond is a thousandth of a second (10^-3 or 0.001).  The
abbreviation is Ims.
A microsecond is a millionth of a second (10^-6 or 0.01).  The
abbreviation is Ius (or more properly IEmicros).
A nanosecond is a billionth (US) of a second (10^-9 or 0.1).
The abbreviation is Ins.

=for example begin

  # The ns part is 0.00230 below
  my $dt_ns = DateTime-new(year = 2003, month = 3,   day = 1,
hour = 6,minute = 55, second = 23,
nanosecond = 230);
  print ns: , $dt_ns-nanosecond, \n;  # Prints: ns: 230\n

  # Assuming we got milliseconds as an argument
  my $ms = 42;
  my $dt_ms = DateTime-new(year = 2003, month = 3,   day = 1,
hour = 6,minute = 55, second = 23,
nanosecond = $ms * 1_000_000);
  print ns: , $dt_ms-nanosecond, \n;  # Prints: ns: 4200\n



=for example end

=for example_testing
  is($_STDOUT_, ns: 230\nns: 4200\n, Nanoseconds);


qr// in 5.00503 [was: Re: Converting to DT]

2003-06-12 Thread Ben Bennett
I knew I had seen the assertion that qr started in 5.6.0 somewhere
recently and finally found it:
  Perl 5.6.0 introduced the ability to package up regular expressions
   into variables using the qr// operator.
  [From Simon Cozen's article on regexps
   http://www.perl.com/pub/a/2003/06/06/regexps.html]

So... given that you have it working on 5.00503 he is clearly in
error.

Does anyone know of a quick reference to show what new syntax was
introduced with a given release?

 -ben

On Wed, Jun 11, 2003 at 04:59:08PM -0500, Dave Rolsky wrote:
 On Thu, 12 Jun 2003, Rick Measham wrote:
 
  At 4:28 PM -0500 11/6/03, Dave Rolsky wrote:
  5.00503 is the goal for all DateTime modules, and anyone writing a DT
  module should have a damn good reason for _not_ supporting it.  qr// does
  indeed work with 5.00503.
 
 
  Since when?
 
  This is perl, version 5.005_03 built for i386-freebsd
 
  I went through seven stage of hell trying to get it installed. IIRC I
  had to hack Time::Local. Can't remember though, all I remember is
  that it wasn't just a case of perl Makefile.PL, make, make test, make
  install.
 
  Does anyone have a legacy system they can try to install on?
 
 Yeah, me.  DT.pm uses qr// internally and I always run tests on 5.00503,
 5.6.1, and 5.8.0 before each release.
 
 
 -dave
 
 /*===
 House Absolute Consulting
 www.houseabsolute.com
 ===*/


Re: 3 letter timezones (was month name to number)

2003-06-11 Thread Ben Bennett
Cool.  I want to mention it in the FAQ and I want to use it in the
Complex parser...

-ben

On Wed, Jun 11, 2003 at 03:33:09PM -1000, Joshua Hoblitt wrote:
  Any progress on this?
 
 I seem to recall that Rick volunteered to do it but I don't see that in the thread.  
 I just started work on it anyways.  If Rick already has something we can just use 
 that instead.
 
 -J
 
 --


Nanoseconds in the FAQ.

2003-06-11 Thread Ben Bennett
I added a section on nanoseconds:

http://www.limey.net/~fiji/perl/faq.html#2.9%3A%20How%20small%20an%20increment%20of%20time%20can%20I%20represent%3F

The raw POD is below.

I deliberately did not mention fractional_second since Dave suggests
that it is going away...  If this is not true, please let me know and
I will add info on it.

   -ben


=head3 How small an increment of time can I represent?

ADateTime can represent nanoseconds.  You can create obects with
that resolution using the Cnanosecond parameter to Cnew or Cset
and there is a corresponding Cnanosecond accessor.  For these you
give an integer count of the nanoseconds.

A millisecond is a thousandth of a second (10^-3 or 0.001).  The
abbreviation is Ims.
A microsecond is a millionth of a second (10^-6 or 0.01).  The
abbreviation is Ius (or more properly IEmicros).
A nanosecond is a billionth (US) of a second (10^-9 or 0.1).
The abbreviation is Ins.

=for example begin

  # The ns part is 0.00230 below
  my $dt_ns = DateTime-new(year = 2003, month = 3,   day = 1,
hour = 6,minute = 55, second = 23,
nanosecond = 230);
  print ns: , $dt_ns-nanosecond, \n;  # Prints: ns: 230\n

  # Assuming we got microseconds as an argument
  my $ms = 42;
  my $dt_ms = DateTime-new(year = 2003, month = 3,   day = 1,
hour = 6,minute = 55, second = 23,
nanosecond = $ms * 1_000_000);
  print ms: , $dt_ms-nanosecond, \n;  # Prints: ms: 4200\n



=for example end

=for example_testing
  is($_STDOUT_, ns: 230\nms: 4200\n, Nanoseconds);



Re: 3 letter timezones (was month name to number)

2003-06-10 Thread Ben Bennett
Any progress on this?

 -ben

On Wed, Apr 30, 2003 at 12:30:01PM +1000, Rick Measham wrote:
  On Tue, 29 Apr 2003, Joshua Hoblitt wrote:
  I was thinking of something similar to the 'constant' syntax that
  quietly creates namespaces.
  
  use DateTime::TimeZone::Alias HST = 'US/Hawaii';
  .
  .
  
  my $dt = DateTime-new( year = 2003, time_zone = 'HST' );
  
  That seems like the most tidy way of doing things.  Of course I won't
  have time to work on this for several days so I may not get a vote. :)
 
 On 30/4/03 11:42 AM, Dave Rolsky at [EMAIL PROTECTED] spake thus:
  The problem is that parsers need more than this, since they can't just set
  a static list of aliases in advance.  They have to be able to have EST be
  interpreted in multiple ways.
 
 I'm looking at setting a range of 'standard' aliases and allowing options:
 
 use DateTime::TimeZone::Alias EST = 'Australia/Melbourne';
 my $dt = DateTime-now( time_zone = 'EST' );
 print $dt-offset;
 # Returns 36000
 
 use DateTime::TimeZone::Alias EST = 'America/New_York';
 my $dt = DateTime-now( time_zone = 'EST' );
 print $dt-offset;
 # Returns -14400 even though EST is standard time and NY is in Daylight time
 because EST is mapped to 'America/New_York'.
 
 use DateTime::TimeZone::Alias;
 my $dt = DateTime-now( time_zone = 'EST' );
 print $dt-offset;
 # Returns -14400 (assumes most people will be thinking about USA).
 
 Apart from the standard zones I'd include other ones like using 'AEST/V' and
 'AEST/M' for Australian Eastern Standard/Summer time in Victoria.
 
 'AEST' would default to Sydney (as would 'AEST/NSW' and 'AEST/S') simply
 because most people would be expecting Sydney (most of the world seem to
 think it's our capital city!)
 
 use DateTime::TimeZone::Alias 'I have a lovely bunch of coconuts' =
 'America/Hawaii';
 my $dt = DateTime-now( time_zone = 'I have a lovely bunch of coconuts' );
 # Obviously the result is Hawaii, I just added this to demonstrate the
 ability to use anything as an alias.
 
 I'd also include the A-Z zones (And might even include Adelaide and other
 1/2 hour zones as 'X.5'!)
 
 Hmmm .. as I type this I wonder if we should also allow aliasing to custom
 zones:
 my %NO_DST = (
 dst_start_month = 0,
 dst_start_day   = 0,
 dst_start_hour  = 0,
 dst_end_month   = 0,
 dst_end_day = 0,
 dst_end_hour= 0,
 offset  = 36000,
 dst_offset  = 36000,
 );
 use DateTime::TimeZone::Alias EST = \%NO_DST;
 my $dt = DateTime-now( time_zone = 'EST' );
 print $dt-offset;
 # Returns 36000
 
 For setting things 'permanently' maybe we should read
 $ENV{DATETIME_TZ_ALIAS} and ~/.DATETIME_TZ_ALIAS
 
 Developers hooking onto aliases really should either:
 1. Provide their own aliases
 2. Provide their own data file
 3. Not mind if things get screwy
 4. Get run over by a large bus.
 
 
 Cheers!
 Rick


Re: Converting to DT

2003-06-10 Thread Ben Bennett
Ah.

I am working on that.  I decided to use Parse::RecDescent as a base.
I have a working ISO8601 (is http://www.w3.org/TR/NOTE-datetime
complete?) and I have it parsing simple dates and times...

Next on my list is making it understand all of the weird and wonderful
things that Date::Manip can do (and more) and making sure that it is
possible to localize it.

The reasons I decided to go with Parse::RecDescent rather than the
regexps that Date::Manip uses:
  1) Expressing it as a grammar is more clear
  2) Parse::RecDescent allows reconfiguration of the rules, so that if
 we need to change stuff when localizing that would work

Some mix of the above also apply to DT::F::Builder too.

However, I have no idea how fast this is and how much memory it
consumes.  I will try to release what I have tonight (when I hope to
have it in a more usable state).

-ben

On Tue, Jun 10, 2003 at 08:39:50AM -1000, Joshua Hoblitt wrote:
  FAQ answers should answer more questions then they generate,
  but two obvious questions leap out of that code...
 
  1. Why is set_time_zone() needed for this DateTime example?
 
 Good point - that should be added to the description.
 
  2. Why use DateTime::Format::*MySQL* when the code may have nothing
 to do with MySQL, it just happens to use the same, very common, format?
 
 It is a mySQL time format.
 
  I do think there should be a DateTime::Format::Common with a
  parse_datetime() that can handle common _unambiguous_ numeric formats.
 
  A single regex could handle all formats that follow the ISO 8601
  general left-to-right decreasing resolution style, with assorted
  optional punctuation, plus optional appended TZ.
 
 Months ago I looked stealing the Date::Manip parser and decided to save that for a 
 very rainy day. :)  I did start to implement all of ISO8601 with DT::F::Builder but 
 I haven't worked on it since April.  Instead of a single large regex I'm going the 
 many small regexs route.  The problem is the ISO8601 defines a lot of unusual date 
 formats - although releasing something with only partial compliance shouldn't be too 
 hard.
 
 I'll try to get something into the workable state and release it later this week.
 
 -J
 
 --
 


Re: Converting to DT

2003-06-10 Thread Ben Bennett
That's too bad.

Anway, I am going to keep playing with this for a bit until I get all
of the functionality I want, then I can convert it to a re-based
thing.

-ben

On Tue, Jun 10, 2003 at 03:30:05PM -0500, Dave Rolsky wrote:
 On Tue, 10 Jun 2003, Ben Bennett wrote:
 
  However, I have no idea how fast this is and how much memory it
  consumes.  I will try to release what I have tonight (when I hope to
  have it in a more usable state).
 
 I played with P::RecDescent for Mason, and it is slow and a memory hog.
 That's no dis to Damian, cause it's a great tool, but in most cases a
 custom regex-based parser is way faster.
 
 
 -dave
 
 /*===
 House Absolute Consulting
 www.houseabsolute.com
 ===*/


Re: What should a business module implement?

2003-06-06 Thread Ben Bennett
Very interesting post.

However, I am interested in knowing what the differences are between
the different calendars.

Are the variables that I mentioned in a previous post sufficient or
have the exchanges done something exceedingly odd in the past.

Why can't you tell what the TOKYO calendar will be until Jan 1st?

I assume that the differences between the US exchange calendars
basically boil down to:
  - Different holidays
  - Different opening hours
  - Different week numbering scheme

In which case DateTime::Sets of holidays and hours will be enough to
handle the first two cases, and some flag will handle the different
week numbers.

I intend to make some convenience factories that will make some
standard holidays (e.g. US federal holidays, each state's holidays,
special bank holidays, etc.), I will worry about that later though.

   -ben


On Thu, Jun 05, 2003 at 01:32:14PM -0700, Brad Hughes wrote:
 Ben Bennett wrote:
 Okay so what should a business date module be able to do?
 
 What is a business day?
 
 A quick glance at our internal date modules reveals over 40 different
 business day calendars.  You've got, for example, the NYSE, NASDAQ,
 AMEX, CBOE, PHIL, Midwest, and Pacific Stock Exchanges, which
 *currently* use the same calendar, though they haven't always.
 And that doesn't include the NYFE and the CBOE and KCBT and the
 other Futures and Commodity exchanges.  And even though they may
 use the same calendar, currently, they're open different hours.
 
 And that's just the U.S.  You also have Tokyo, Osaka, Nagoya,
 Hong Kong, Toronto, Paris, Zurich, Frankfort, and at least 3 flavors
 of London market calendars.
 
 Oh, and in the U.S. there's a separate Bank Holiday calendar, which
 is different than the Federal Holiday calendar.  And I believe each
 state in the U.S. has its own notion of business calendars (did you
 know that in Texas in January you can celebrate either Martin Luther
 King Day or Confederate Heroes Day;  they were merged when Texas
 agreed to observe MLK Day).
 
 (As an aside, this plethora of possible calendars was the reason I
 objected to DT:: using ::Calendar to refer to how dates were described
 (Gregorian, Mayan, Ancient Sikh Moon, etc) instead of what they represent
 (NYSE, BANK, FEDERAL, etc) in an earlier ignored post.  It just seems to
 me that ::Calendar is too perfect a word to waste on something that will
 default to Gregorian in the vast majority of cases instead of available
 for what I believe will be the more common need to describe different
 business day calendars.)
 
 In any case, my suggestion is, for each calendar, take a scalar where
 
   1) each bit represents a calendar day, starting from some start date
  (data is available for the NYSE going back to 1885, when the NYSE
  had a special closing for the funeral of Ulysses S. Grant);
   2) a bit is 1 if that day is a valid day for that calendar;
   3) the scalar is uuencoded and stuck in a __DATA__ section.
 
 The tough part is keeping these uuencoded bitstrings accurate, one for
 each calendar.  You can know pretty well what the BANK or NYSE
 calendar will be for some time in the future, except for things like
 special closings for a president's funeral or Sep 11.  TOKYO is another
 matter;  sometimes you're not sure what a year's going to look like
 until Jan 1.
 
 Perhaps datetime.perl.org could be the repository of a master copy
 which changes when need be, and some mechanism to verify and update
 a local copy be made available.  This doesn't work well for sites
 isolated from the net, but they'll cope.
 
 brad


Re: What should a business module implement?

2003-06-06 Thread Ben Bennett
I think I am leaning towards the following:

Have a module that can perform special date arithmetic.  So you load
the definition of good times and bad into an object (through the
constructor and accessors) and can then perform calculations on dates
as calls through the object.

Something like:
---
  my $holidays   = DateTime::Format::ICal-new(...);
  my $work_hours = DateTime::Event::Recurrence-daily(...)
  my $business   = DateTime::Calc::Business-new
 (holidays   = $holidays,
  work_hours = $work_hours,
 );
  my $dt1 = DateTime-new( ... );
  my $dt2 = $business-add( days = 2 ); # Takes a DT::Duration too
  
  etc.
---

Does this sound vaguely plausible?

 -ben

On Thu, Jun 05, 2003 at 06:24:24PM -0300, Flavio S. Glock wrote:
 Another one:
 
 http://iCalShare.com
 - A lot more calendar tables.
 
 Flavio S. Glock wrote:
  
  Some links that might be useful:
  
  http://www.apple.com/ical/library
  - Very good files, can be read using
DateTime::Format::ICal
and a bit of hacking. Includes bank holidays.
I don't know what the license is.
  
  http://www.angelinn.net/cal_info.htm
  - links for sites that have more
calendar tables.
  
  http://www.bank-holidays.com
  - not useful, just for fun.


What should a business module implement?

2003-06-05 Thread Ben Bennett

Okay so what should a business date module be able to do?

As a first cut:
 - Business day arithmetic:
   - Addition
   - Subtraction
   - Differences (how many b. days between X and Y)
 - Know about holidays
 - Have settable weekend day(s)
 - Know about business hours
 - Way to say if a given DT is during business hours
 - Way to say if a given DT is a business day

Unknown:
 - Week numbers?
 - Week days within that?

For each setting I think there should be some defaults baked into the
module that are overridable per-site and then per-object within the
code.

I am intentionally disregarding the interface to the thing initally
until I have a better grasp of what it is expected to be able to do.

  Please throw out suggestions for needed functionality,

-ben



Re: installing DateTime-TimeZone-0.17 on HPUX 10.20... or Cygwin

2003-06-03 Thread Ben Bennett
I will add it to the FAQ...

-ben

On Mon, Jun 02, 2003 at 07:46:54AM -0700, Hill, Ronald wrote:
 
 Hi Jean  Ben,
  
  From Ben Bennet (Fri, 30 May 2003 15:24:13 -0400)
  OK, it looks like it is bombing because of all of the modules to
  install... each timezone module looks like:
  
 [snipped]
  
  This is a tough problem to solve... the easiest thing might be to try
  gnu make since that appears to be smart enough to handle arbitrarily
  long strings.  The fix probably needs to occur in MakeMaker though...
  Might be worth dropping them an email with the example.
  
  -ben
  
  I have a similar problem with make for cygwin 
 
 [snipped]
 
  The workaround I used was to type
 make -n  make-n.sh
  then edit make-n.sh to replace the 32K line
 -e yada yada yada
  by calling a make-n.pl Perl script, which contains one 32K line.
  
  May be a new item in the FAQ could be sufficient...
  
  Jean Forget
 
 I was not able to get this to work with the HP make utility
 However, I installed gmake and it works!!! I was able to 
 install the DateTime-TimeZone-0.17. Where do we document
 these kinda things?
 
 Ron Hill


Re: installing DateTime-TimeZone-0.17 on HPUX 10.20... or Cygwin

2003-06-03 Thread Ben Bennett
I still think it is a MakeMaker problem, has anyone reported it to
them?

I plan on adding it to the FAQ until we get it resolved properly.

-ben

On Mon, Jun 02, 2003 at 08:24:24AM -0700, Hill, Ronald wrote:
 Hi John,
 
  Rather than document it, is there any way to fix the Makefile 
  to have 32 1k lines instead of 1 32k line?  
 
 I guess I was not clean as what I was refering to when I
 made the statement of Document it. What I should have
 asked is Is there a place to document the test results
 that I have Sorry, I should have been more clear.
 
 However, I agree the this needs to be fixed in the 
 makefile.
 
  Having to require a specific make/gmake is really 
  not a good plan.  It should be very unusual to require some 
  different helper utility like 'gmake' to build an 
  extension to Perl when that resident 'make' can 
  build Perl itself.
  
  John
  
 You are absolutely correct!!
 
 
 Ron Hill


FAQ outstanding questions...

2003-06-03 Thread Ben Bennett
Typos in POD that I spotted during FAQ development:

1) DateTime::Format::Strptime: This method is synonymous with
   DateTime's strptime method.

2) DateTime: DateTime does not if second values greater than 59 are
   valid based on current leap seconds, and invalid values simply
   cause an over-flow.


Questions that came up in the FAQ development (you can also see these
in the FAQ in the correct context if you search for QUESTION):

1) Is it worthwhile to add an optional resolution argument to compare
   to allow easier usage?  (There was discussion, but I don't think we
   came down anywhere)

2) What is the overlap between DateTime::Format::Builder and
   DateTime::Format::Strptime?  Which is preferred?

3) QUESTION How do you print non 0 or space padded years and months?
   [in strftime]

4) Wasn't this [the DateTime constructor croaking on bad dates] going
   to be overridable?

5) What happened to the module that was going to handle guessing? [at
   short timezone names]

6) Is there something equivalent for two days from the end of the
   month?  Should there be?  Perhaps the flag should say whether the
   start or end of the month offset is what matters... [In
   DateTime::Duration]

7) Do Sets constructed from explicit dates always get sorted?

8) Should DateTime::Set have a way to add an more explicit dates
   without having to make a new set and union it in?

9) Do we need a DateTime::Set clone method (ditto span, etc.)?

10) Did we ever work out how to attatch information to a date from a
set? [I remember a proposal floating about, I will have to look at
the archives]

11) Are we going to return an object for +/-inf or will it always be a
string? [I remember some discussion here, how did it turn out?]

12) Is that true about the SpanSet? If so the docs are wrong. [What
does DateTime::Set-complement() (unary) return, a Set or a
SpanSet, if a Set, what does it mean (the returned type is
currently a Set, but the values are odd]

13) How do I set a time zone on a set? (and span and spanset)

There are some other questions about alternate implementations and
business logic that I need to think about (unless someone else has any
bright ideas).


   Thanks,

-ben


Re: ANNOUNCE: Object::Stringify

2003-06-02 Thread Ben Bennett
Ah, interesting, I missed those packages when searching for prior
art.  Class::Decorator seems not to allow what I want (new arbitrary
methods) but instead seems to allow you to insert pre and post code.
Class::Wrapper is closer but I don't think it is compatible because of
all the hackery I have to do to get the inheritence right for
overloaded operations (I have to make a package on the fly to get the
ISA magic right).

That said the Class namespace might be better than the Object one I am
currently using, perhaps Class::Overload::Stringify?

I thought about implementing a way to do all of the overloadable
operators, but there are some nasty twists that way...  Perhaps I will
look at that again.

-ben

On Sun, Jun 01, 2003 at 12:02:06PM -0500, Dave Rolsky wrote:
 On Fri, 30 May 2003, Ben Bennett wrote:
 
  This class allows you to wrap an arbitrary object and provide
  stringification and numification methods while changing the interface
  to the object as little as possible.
 
 Have you taken a look at Class::Decorator on CPAN?  What you've
 implemented is more or less the decoration pattern, but specifically
 oriented at overloading.  I'd suggest either offering a patch to
 Class::Decorator to allow for overloading or to implement a
 Class::Decorator::Overload module that uses Class::Decorator and adds
 overloading, if the author doesn't accept your patch.
 
 
 -dave
 
 /*===
 House Absolute Consulting
 www.houseabsolute.com
 ===*/


Re: Fw: Hijri dates

2003-05-31 Thread Ben Bennett
Claus Tondering's calendar FAQ[1] has some information about this in
sections 4.2 and 4.5.

4.5 says that Saudi Arabia has adopted a calendar based on a
calculated astronomical moon (at Mecca).

This is actually the reason that I wanted to get a Moonrise package
working...


-ben


Re: Rough first draft of a FAQ

2003-05-31 Thread Ben Bennett
On Fri, May 30, 2003 at 12:36:17PM -0500, Dave Rolsky wrote:

 The archives are linked on the mailing list page and the modules page has
 links to each module's CPAN page.

OK.  At the very least I want to leave a link to the top of
datetime.perl.org in case they came in using a link fron elsewhere
(e.g. google).

I will probably leave the tip for how to search the archives with
google unless you are strongly opposed.


How do you want to progress from here... I will try and get the TODO
items cleaned up and have a look at the grouping and ordering.  At
some point I should get CVS access and commit the stuff.

-ben


Re: Rough first draft of a FAQ

2003-05-31 Thread Ben Bennett
I would not be opposed, but I think we should let the FAQ settle a bit
before rolling stuff into the core.

Some of the items are really the DT::Business that Dave mentioned
earlier.

Perhaps others belong in DT itself or in DT::Calc.

One reason that I sort of think the latter is that you want to be able
to define what a week is.  You may be using the ISO week (which may be
in a different year) or a different start day for the week (e.g. Saudi
Arabia has the weekend on Friday and Saturday, I dunno if that is
common in other Islamic countries).  So you need a way to set that
calculation wide, so you may need to do something like:

use DT::Calc qw(:constants);

my $calc = DT::Calc-new(week_starts_with = MONDAY);
$calc-get_day_in_same_week($dt, THURSDAY);

or somesuch.  The sub names are pretty ugly so I am open to
suggestions for better ones.

 -ben


On Fri, May 30, 2003 at 01:46:57PM -0500, Dave Rolsky wrote:
 On Fri, 30 May 2003, Dan Sully wrote:
 
  * Ben Bennett [EMAIL PROTECTED] shaped the electrons to say...
 
   I have a (very) rough draft of a faq available at:
 http://www.limey.net/~fiji/perl/
 
  Ben - I like the FAQ a lot. A suggestion though - you offer quite a few
  functions that do useful things, ie: get_day_in_same_week, etc.
 
  It'd be useful (to me at least) if those made it into a DateTime::Helpers or 
  somesuch.
 
 Or maybe just into the core.  I'm open to adding more methods, as long as
 they provide something useful that people would otherwise end up
 re-implementing in their own code.
 
 
 -dave
 
 /*===
 House Absolute Consulting
 www.houseabsolute.com
 ===*/


Bug in DateTime::Span-contains()

2003-05-30 Thread Ben Bennett

Actually there are two bugs (yes my sandbox is current).

The first is fixed by the patch below (it creates an unused $tmp
DateTime::Span object without the required args).

The second is more tricky... DT::Span tries to create a DT::Set
object, but doesn't use DT::Set.  This is nasty to fix since DT::Set
uses DT::Span, so you don't want to make a circular dependency.  I am
not sure how best to fix this.

A script to catch this is:

---
use DateTime;
use DateTime::Span;

my $low_date  = DateTime-new(year = 2002, month = 3, day = 1);
my $high_date = DateTime-new(year = 2002, month = 2, day = 11);
my $test_date = DateTime-new(year = 2002, month = 2, day = 23);

# Make sure the high is higher than the low
($low_date, $high_date) = ($high_date, $low_date)
  if $low_date  $high_date;

# Make the span (note that we don't need to flip the dates)
my $span = DateTime::Span-from_datetimes(start = $low_date,
end   = $high_date);

if ($span-contains($test_date)) {
  print '$test_date is between the given dates';
}
---

  -ben


Index: lib/DateTime/Span.pm
===
RCS file: /cvsroot/perl-date-time/modules/DateTime-Set/lib/DateTime/Span.pm,v
retrieving revision 1.20
diff -u -r1.20 Span.pm
--- lib/DateTime/Span.pm8 May 2003 00:35:32 -   1.20
+++ lib/DateTime/Span.pm30 May 2003 02:36:20 -
@@ -159,7 +159,7 @@
 sub intersects {
 my ($set1, $set2) = @_;
 my $class = ref($set1);
-my $tmp = $class-new();
+my $tmp = {}; # $class-new();
 $set2 = DateTime::Set-new( dates = [ $set2 ] ) unless $set2-can( 'union' );
 return $set1-{set}-intersects( $set2-{set} );
 }
@@ -167,7 +167,7 @@
 sub contains {
 my ($set1, $set2) = @_;
 my $class = ref($set1);
-my $tmp = $class-new();
+my $tmp = {}; # $class-new();
 $set2 = DateTime::Set-new( dates = [ $set2 ] ) unless $set2-can( 'union' );
 return $set1-{set}-contains( $set2-{set} );
 }


Re: Bug in DateTime::Span-contains()

2003-05-30 Thread Ben Bennett
Sorry to reply to myself, but the problem is even more interesting,
DateTime::Set doesn't have a constructor named new.  Perhaps the right
thing to do is call DateTime::Span-new(), but I leave that to less
tired people to work out.

  -ben

On Thu, May 29, 2003 at 10:41:12PM -0400, Ben Bennett wrote:
 
 Actually there are two bugs (yes my sandbox is current).
 
 The first is fixed by the patch below (it creates an unused $tmp
 DateTime::Span object without the required args).
 
 The second is more tricky... DT::Span tries to create a DT::Set
 object, but doesn't use DT::Set.  This is nasty to fix since DT::Set
 uses DT::Span, so you don't want to make a circular dependency.  I am
 not sure how best to fix this.
 
 A script to catch this is:
 
 ---
 use DateTime;
 use DateTime::Span;
 
 my $low_date  = DateTime-new(year = 2002, month = 3, day = 1);
 my $high_date = DateTime-new(year = 2002, month = 2, day = 11);
 my $test_date = DateTime-new(year = 2002, month = 2, day = 23);
 
 # Make sure the high is higher than the low
 ($low_date, $high_date) = ($high_date, $low_date)
   if $low_date  $high_date;
 
 # Make the span (note that we don't need to flip the dates)
 my $span = DateTime::Span-from_datetimes(start = $low_date,
 end   = $high_date);
 
 if ($span-contains($test_date)) {
   print '$test_date is between the given dates';
 }
 ---
 
 -ben
 
 
 Index: lib/DateTime/Span.pm
 ===
 RCS file: /cvsroot/perl-date-time/modules/DateTime-Set/lib/DateTime/Span.pm,v
 retrieving revision 1.20
 diff -u -r1.20 Span.pm
 --- lib/DateTime/Span.pm8 May 2003 00:35:32 -   1.20
 +++ lib/DateTime/Span.pm30 May 2003 02:36:20 -
 @@ -159,7 +159,7 @@
  sub intersects {
  my ($set1, $set2) = @_;
  my $class = ref($set1);
 -my $tmp = $class-new();
 +my $tmp = {}; # $class-new();
  $set2 = DateTime::Set-new( dates = [ $set2 ] ) unless $set2-can( 'union' );
  return $set1-{set}-intersects( $set2-{set} );
  }
 @@ -167,7 +167,7 @@
  sub contains {
  my ($set1, $set2) = @_;
  my $class = ref($set1);
 -my $tmp = $class-new();
 +my $tmp = {}; # $class-new();
  $set2 = DateTime::Set-new( dates = [ $set2 ] ) unless $set2-can( 'union' );
  return $set1-{set}-contains( $set2-{set} );
  }


Re: Rough first draft of a FAQ

2003-05-30 Thread Ben Bennett
On Thu, May 29, 2003 at 11:59:21PM -0500, Dave Rolsky wrote:

 First I'll pick some nits.
 
 - Assume it will be hosted on datetime.perl.org, so you can skip the first
 4 questions.

I dunno, 1.1 to govern the scope of the FAQ seemes relevant as does
the reference to Claus' FAQ in 1.3.  I haven't seen 1.4 (searching)
anywhere but as a post to the list itself (which reminds me, I should
use the search to see who suggested that method).

Are we sure that datetime.perl.org will be the only place for the FAQ?
Will it be distributed with the module ever?

Should I add a section on how to install it?

Anyway, I will revise it given the assumption that it is on
datetime.perl.org.

 
 - Please don't use fixed number offsets for the time zone examples.  This
 only encourages broken code when people do this in real apps when instead
 they should use a named time zone.

Fair enough.  I had that originally, but thought it was more clear
with explicit numbers.  I will change it.  (BTW the DateTime POD uses
offsets when explaining set_time_zone)


 Now to answer specific questions:
 
 2.3: Why do I need to truncate dates?
 
 QUESTION Is it worthwhile to add an optional resolution argument to
 compare to allow easier usage?
 
 Maybe.  My theory is that most people will take advantage of overloading
 and just use Perl's built-in comparison operators.

Agreed, but when you want to compare things at a different resolution
now you may have to:
--
$dt1 = $dt1-clone()-truncate(to = 'day');
$dt2 = $dt2-clone()-truncate(to = 'day');
if ($dt1 = $dt2) { ... }
--

Rather than:
$dt1-compare($dt2, {to = 'day'});

Admittedly the second is way more ugly if you need to do lots of
comparisons with the dates, but the case I think it is a big win is
with sorting since you can just use the resolution argument in the
comparator without having to (possibly) clone and truncate the dates
in the original sort list.

 2.4: What is the floating time zone?
 
 QUESTION Should compare_ignore_floating take an optional timezone
 argument? (See also the possible argument for resolution...)
 
 I think the section of the floating time zone should have a big fat
 warning that mixing floating time zones and real time zones is likely to
 lead to a mess.  The floating time zone option exists for people who want
 to abstract datetime stuff.  Mixing it with actual time zones, unless
 you really understand why you're doing so, is bound to lead to trouble.
 
 All of which doesn't answer your question, but the point is I don't want
 to make mixing floating  non-floating so easy that people don't think
 twice before doing so.

Fair enough.  Added the warning.

 2.21: How can I calculate the last business day (payday!) of a month?
 
 QUESTION: Do we do anything with business logic?
 
 No, I'm waiting for someone to writing a DateTime::Business module.  Any
 takers?

Mebbe.  I have learned quite a bit about the modules from writing the
FAQ.

-ben