DateTime.pm on Win32?

[Dave Rolsky]

Any progress on this?  If not, I'll probably throw in a hack in the
DateTime.xs to just not compile _normalize_seconds on Win32, because I
really want to make a new release of DateTime.pm, and I don't want to wait
much longer for the Win32 fixes.


-dave

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

Re: Rough ISO8601 parser ready...

[Joshua Hoblitt]

> I'm inclined to say completeness is more important than speed in this
> case.  Optimizations can always be done later anyway.

They'll both be complete for Date + Date and Time formats.  Just times can't be done 
with DT.  The difference is in supporting recurrences, durations, and the user being 
able to specify which formats to parse.

-J

--

Re: Rough ISO8601 parser ready...

[Dave Rolsky]

On Fri, 20 Jun 2003, Joshua Hoblitt wrote:

> We are thinking about having two different modules.  Or I'm willing to
> throw mine away if it's just going to be superfluous.
>
> DateTime::Format::ISO8601::Complex
> DateTime::Format::ISO8601::Simple
>
> The question is should there be a DT::Format::ISO8601 module?  And if so
> which module should it be.  I'm more or less indifferent as which way to
> go.  Ben's module will cover much more of ISO8601 then mine.

I'm inclined to say completeness is more important than speed in this
case.  Optimizations can always be done later anyway.


-dave

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

Re: Rough ISO8601 parser ready...

[Joshua Hoblitt]

On Sat, 21 Jun 2003, Iain Truskett wrote:

> * Ben Bennett ([EMAIL PROTECTED]) [21 Jun 2003 14:18]:
> > I have made my rough ISO8601 parser available at:
> >   http://www.limey.net/~fiji/perl/DateTime-Format-ISO8601-0.01.tar.gz
>
> Could you check it into the CVS please?

A name needs to be settled on first.

Ben and I have had some discussion and we've taken completely different and 
incompatible approaches.  My parser only does Dates + Date/Time formats and although 
very simple in scope it should be pretty fast with length matching.  Not to mention I 
didn't finish it two months ago like I should have.  Ben's module has a very large 
scope and should eventually do recurrences/durations (pretty neat) although there is 
some startup overhead it could be just as fast.

We are thinking about having two different modules.  Or I'm willing to throw mine away 
if it's just going to be superfluous.

DateTime::Format::ISO8601::Complex
DateTime::Format::ISO8601::Simple

The question is should there be a DT::Format::ISO8601 module?  And if so which module 
should it be.  I'm more or less indifferent as which way to go.  Ben's module will 
cover much more of ISO8601 then mine.

-J

--

Re: Rough ISO8601 parser ready...

[Dave Rolsky]

On Sat, 21 Jun 2003, Ben Bennett wrote:

>  - Module name not settled yet

What other name would you use?  DT::F::ISO8601 seems pretty logical to me.

Why not check it in with this name?


-dave

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

Re: [rfc] DateTime::Util

[Dave Rolsky]

On Fri, 20 Jun 2003, Joshua Hoblitt wrote:

> > I can't think of any other usage which necessitates such a constructor.
>
> strptime needs it.

Actually, if we're going to emulate the C library's strptime() then it's a
_different_ week number.  In fact, there's two different ones strptime()
handles, for %O and %W!

So a constructor wouldn't really help in this case.


-dave

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

Re: Rough ISO8601 parser ready...

[Iain Truskett]

* Ben Bennett ([EMAIL PROTECTED]) [21 Jun 2003 14:18]:
> I have made my rough ISO8601 parser available at:
>   http://www.limey.net/~fiji/perl/DateTime-Format-ISO8601-0.01.tar.gz

Could you check it into the CVS please?


cheers,
-- 
Iain.

Rough ISO8601 parser ready...

[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: [rfc] DateTime::Util

[Joshua Hoblitt]

> I can't think of any other usage which necessitates such a constructor.

strptime needs it.

-J

--

Re: ANNOUNCE: DateTime::Locale - new release for feedback

[Dave Rolsky]

On Sat, 21 Jun 2003, Richard Evans wrote:

> The one exception to this would be additions, and in that case I can generate
> any new locales for the time being - I'm not saying that I'll never release
> the generator code, simply that it's not feasible in the short term.

Why isn't it feasible?  Just release it and I'll clean it up if necessary.

I'm not willing to check in generated code without having the generator
available, though.  If you're really not willing to release yours, I'll
just write one from scratch that generates the same output.


-dave

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

Re: [rfc] DateTime::Util

[Dave Rolsky]

On Sat, 21 Jun 2003, Ben Bennett wrote:

> I saw that mail, but I meant yet another constructor that will take an
> ISO week number and day number (within the week) and a "year"
> construct the appropriate date.
>
> Note that the year given may not be the actual year the date falls in
> but is rather the ISO year number.  (For instance day 1 of week 1 of
> 2003 is 2002-12-30!)
>
> You can manaully do this by doing:
> --
> my $dt = DateTime->new(year => $year, month => 1, day => 4);
> my $adjustment =
>( ($week_num - 1) * 7   ) +
>(  $day_num - 1 ) -
>(  $dt->day_of_week - 1 );
> $dt->add($adjustment);

In which case this belongs in the DateTime::Format::ISO8601 module, since
the only people likely to want to construct an object based on
ISO week-year stuff are going to use that module anyway.

I can't think of any other usage which necessitates such a constructor.


-dave

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

Re: [rfc] DateTime::Util

[Ben Bennett]

I saw that mail, but I meant yet another constructor that will take an
ISO week number and day number (within the week) and a "year"
construct the appropriate date.

Note that the year given may not be the actual year the date falls in
but is rather the ISO year number.  (For instance day 1 of week 1 of
2003 is 2002-12-30!)

You can manaully do this by doing:
--
my $dt = DateTime->new(year => $year, month => 1, day => 4);
my $adjustment = 
   ( ($week_num - 1) * 7   ) + 
   (  $day_num - 1 ) -
   (  $dt->day_of_week - 1 );
$dt->add($adjustment);
--

  -ben


On Fri, Jun 20, 2003 at 05:08:09PM -1000, Joshua Hoblitt wrote:
> On Fri, 20 Jun 2003, Ben Bennett wrote:
> 
> > 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.
> 
> I still think there might be a need for DT::Util but for this case (I was thinking 
> of ISO8601 as well) there is another constructor.
> 
> To quote Dave:
> 
> Date: Fri, 20 Jun 2003 16:09:42 -0500 (CDT)  
>  From: Dave Rolsky <[EMAIL PROTECTED]>   
>  
>   To: Ben Bennett <[EMAIL PROTECTED]>
>  Cc: Rick Measham <[EMAIL 
> PROTECTED]>, "Hill, Ronald" <[EMAIL PROTECTED]>, "'[EMAIL PROTECTED]'" <[EMAIL 
> PROTECTED]>  Subject: Re: Having problems with Datetime-format-Strptime-1.02 install 
>  on Wi n32   
>  
>   On Fri, 20 Jun 2003, Ben Bennett wrote:
>  
>  
>> Personally I think this is a good reason to either add a 
> new> DateTime 
> constructor or to add the flag that relaxes the parameter
>   > validation and allows rollovers. 
>  
>  
>There is a DateTime->from_day_of_year 
> constructor. 
>  
>  
>  
> -dave
>  
>  
>  /*===   
>   House Absolute 
> Consulting   
>   www.houseabsolute.com  
>
> ===*/
> 

Re: [rfc] DateTime::Util

[Joshua Hoblitt]

On Fri, 20 Jun 2003, Ben Bennett wrote:

> 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.

I still think there might be a need for DT::Util but for this case (I was thinking of 
ISO8601 as well) there is another constructor.

To quote Dave:

Date: Fri, 20 Jun 2003 16:09:42 -0500 (CDT)
   From: Dave Rolsky <[EMAIL PROTECTED]>   
   
To: Ben Bennett <[EMAIL PROTECTED]>
 Cc: Rick Measham <[EMAIL PROTECTED]>, "Hill, 
Ronald" <[EMAIL PROTECTED]>, "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>  Subject: Re: 
Having problems with Datetime-format-Strptime-1.02 install  on Wi n32  
   
 On Fri, 20 
Jun 2003, Ben Bennett wrote:   
   
   > 
Personally I think this is a good reason to either add a new   
 > DateTime constructor or to add the flag 
that relaxes the parameter 
 > validation and allows rollovers.
   
   
There is a DateTime->from_day_of_year constructor. 
   
   
   
  -dave
   
   
 /*=== 

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

Re: [rfc] DateTime::Util

[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
> 
> --

Re: Business Dates

[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: Slides from YAPC presentation

[John Peacock]

Joshua Hoblitt wrote:
This is as far forward as their schedules are posted:

http://www.mcmenamins.com/Theaters/?theater=All&viewdate=2003-06-26

Hmmm, could be interesting...

John

--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747

Re: Slides from YAPC presentation

[Joshua Hoblitt]

> which opens Friday night?  Is there a decent movie theatre downtown?

Theres several - but wouldn't you rather be in a theater you can drink in?  (and has 
brewery and a distillery on site)

This is as far forward as their schedules are posted:

http://www.mcmenamins.com/Theaters/?theater=All&viewdate=2003-06-26

-J

--

Re: Slides from YAPC presentation

[John Peacock]

Joshua Hoblitt wrote:
I'm actually from Portland and arriving on the 27th of June if anyone wants to get together before/during/after OSCON.

I'm getting in July 5 and not leaving until the 12th (cheaper fares, don't you 
know ;).  I wonder if it would be worthwhile to try and get a BOF together for

	http://www.lxgmovie.com/

which opens Friday night?  Is there a decent movie theatre downtown?

John

--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747

Re: ANNOUNCE: DateTime::Locale - new release for feedback

[Joshua Hoblitt]

> What will happen is end users find errors in the locale stuff, report it to
> DateTime or me, it gets forwarded to OpenI18N, who may or may not apply it
> when they feel so inclined - we'll have to wait like mugs, and users will get
> p*ssed off by the slow turnaround.

I agree with you here but maybe they'll eventually get better...

> > that'll be a big mess come the next ICU update, and it doesn't really
> > matter if that's one month or one year from now, because I'm hoping to
> > continue using this code for a long time.

But that doesn't stop you from including the generator.  Just in case...

> The one exception to this would be additions, and in that case I can generate
> any new locales for the time being - I'm not saying that I'll never release
> the generator code, simply that it's not feasible in the short term.

Maybe a list of additions and modules that have been modified from the generated 
versions.

-J

--

Re: Slides from YAPC presentation

[Joshua Hoblitt]

> > Btw - Is anyone headed to OSCON?
>
> I'll be there.  There's also a Perl datetime BOF scheduled for Thursday
> night from 8-9.

Theres a pdx.pm meeting on Wednesday from 7-10 if your interested.

I'm actually from Portland and arriving on the 27th of June if anyone wants to get 
together before/during/after OSCON.

-J

--

Re: ANNOUNCE: DateTime::Locale - new release for feedback

[Richard Evans]

On Saturday 21 Jun 2003 12:03 am, Dave Rolsky wrote:
> On Sat, 21 Jun 2003, Richard Evans wrote:
> > I'm suggesting I donate all the DT::Locale code to the DT project next
> > week, then anyone with CVS access can hack away to their hearts content -
> > I wouldn't be in "control" of it any more.
> >
> > If you want to give me CVS access as well, that's entirely up to you, but
> > I would be happy to concentrate on other things for a while.
> >
> > Does that make sense, or am I missing the point? (wouldn't be the first
> > time
> >
> > :)
>
> I'm really confused.  Aren't we assuming that _eventually_ the ICU project
> will update its data?  And when that happens, we'll need to regenerate
> _all_ the DT::Locale code, right?  So if we hack on the _generated_ code,

Yes, ICU will undoubtedly release future updates, but when, and how frequently 
is anyones guess - my experience so far suggests this could be a long and 
frustrating wait.

What will happen is end users find errors in the locale stuff, report it to 
DateTime or me, it gets forwarded to OpenI18N, who may or may not apply it 
when they feel so inclined - we'll have to wait like mugs, and users will get 
p*ssed off by the slow turnaround.

> that'll be a big mess come the next ICU update, and it doesn't really
> matter if that's one month or one year from now, because I'm hoping to
> continue using this code for a long time.

My suggestion is that the current release is the one and only generated 
release, and user supplied fixes get applied directly to the CVS code from 
this point onwards.

That will be far easier IMHO, and it means we wouldn't have any pressing need 
to regenerate from ICU in the future.

The one exception to this would be additions, and in that case I can generate 
any new locales for the time being - I'm not saying that I'll never release 
the generator code, simply that it's not feasible in the short term.

Cheers,
-- 
Rich
[EMAIL PROTECTED]

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

[Joshua Hoblitt]

> There's been a lot of discussion about it which I unfortunately couldn't
> follow.  Now it's up to 0.04 and seems to have a lot of functionality, and
> I really don't see the point of all of it.  And even worse, it's gotten
> _more_ intimate the with DT::TZ internals, instead of less.

There was a lot of discussion. :)

If it doesn't show up in the archives I can paste a thread together for you.

DT::TZ::LINKS is still the only internal structure that is modified.

> Why do we need something like is_timezone()?  And if it's needed, it

So you can tell the difference between US/Hawaii and Pacific/Honolulu.  Which may seem 
perfectly clear to you but unless you look at the internal data structure is probably 
not to most people.

> almost certainly does not belong in a module called Alias!  Why does it

Probably not - but what ever module handles the aliasing should have a complete 
interface as it's all related functionality.  This was missing elsewhere.  Maybe we 
should talk about moving this into the DT::TZ dist.

> have the timezones() method which completely duplicates the functionality
> of DateTime::TimeZone::all_names()!

Because all_names() returns a direct reference to the data structure and I was worried 
about protecting the internals.  And as I stated above it's all related functionality.

> All of the stuff about dying if an alias is defined and so on seems like
> total overkill.  The purpose of this module, AFAIC, is for individual
> end-users to be able to define some useful _local_ aliases, in an

This is related to comments made about using this module under mod_perl.  I think it's 
clear that a lot of people will use this to handle localization of timezones (like 
what EST is defined as).

> environment _they_ control.  No one should ever be distributing a CPAN
> module that uses this, and distributing an app that does this by default
> would almost certainly be a bad thing too.

But they will...  And why shouldn't someone be able to define what timezone X means to 
them in a distributed app?  I this passes the 'is it useful' test.

-J

--

Re: ANNOUNCE: DateTime::Locale - new release for feedback

[Dave Rolsky]

On Sat, 21 Jun 2003, Richard Evans wrote:

> I'm suggesting I donate all the DT::Locale code to the DT project next week,
> then anyone with CVS access can hack away to their hearts content - I
> wouldn't be in "control" of it any more.
>
> If you want to give me CVS access as well, that's entirely up to you, but I
> would be happy to concentrate on other things for a while.
>
> Does that make sense, or am I missing the point? (wouldn't be the first time
> :)

I'm really confused.  Aren't we assuming that _eventually_ the ICU project
will update its data?  And when that happens, we'll need to regenerate
_all_ the DT::Locale code, right?  So if we hack on the _generated_ code,
that'll be a big mess come the next ICU update, and it doesn't really
matter if that's one month or one year from now, because I'm hoping to
continue using this code for a long time.


-dave

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

Re: ANNOUNCE: DateTime::Locale - new release for feedback

[Richard Evans]

On Friday 20 Jun 2003 11:38 pm, Dave Rolsky wrote:
> On Sat, 21 Jun 2003, Richard Evans wrote:
> > The conversion script is a horrible mess - it's part of the other locale
> > stuff I was (maybe still am) doing, and uses 10 other modules that are in
> > a state of flux ATM. I also have a horrible feeling the ICU .xml file
> > format had changed last time I looked at the CVS code.
> >
> > Based off the glacial response I've got from the openI18N guys - "yeah,
> > that looks wrong, we'll fix it" - now one and a half months later and no
> > change yet - my gut feeling is that the Locale data should go into CVS as
> > it is now.
> >
> > Corrections and additions would then go directly into the DT::Locale CVS
> > rather than waiting weeks for fixes to get put into the ICU locales.
> >
> > But I'm guessing that's not what you have in mind - do you want the
> > DT::Locale code as it stands to go in, or are you only really interested
> > in the conversion script? If it's the latter, I'll try to get it into a
> > maintainable state, but that will take a while longer, no question about
> > that!
>
> We can't put the generated code in CVS without the generator.  We need to
> be able to make changes in stuff like Locale.pm without having to email
> you and ask you to do it.

Sorry, I don't get what you mean.

I'm suggesting I donate all the DT::Locale code to the DT project next week, 
then anyone with CVS access can hack away to their hearts content - I 
wouldn't be in "control" of it any more.

If you want to give me CVS access as well, that's entirely up to you, but I 
would be happy to concentrate on other things for a while.

Does that make sense, or am I missing the point? (wouldn't be the first time 
:)

Cheers,
-- 
Rich
[EMAIL PROTECTED]

Re: ANNOUNCE: DateTime::Locale - new release for feedback

[Dave Rolsky]

On Sat, 21 Jun 2003, Richard Evans wrote:

> The conversion script is a horrible mess - it's part of the other locale stuff
> I was (maybe still am) doing, and uses 10 other modules that are in a state
> of flux ATM. I also have a horrible feeling the ICU .xml file format had
> changed last time I looked at the CVS code.
>
> Based off the glacial response I've got from the openI18N guys - "yeah, that
> looks wrong, we'll fix it" - now one and a half months later and no change
> yet - my gut feeling is that the Locale data should go into CVS as it is now.
>
> Corrections and additions would then go directly into the DT::Locale CVS
> rather than waiting weeks for fixes to get put into the ICU locales.
>
> But I'm guessing that's not what you have in mind - do you want the DT::Locale
> code as it stands to go in, or are you only really interested in the
> conversion script? If it's the latter, I'll try to get it into a maintainable
> state, but that will take a while longer, no question about that!

We can't put the generated code in CVS without the generator.  We need to
be able to make changes in stuff like Locale.pm without having to email
you and ask you to do it.


-dave

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

Re: ANNOUNCE: DateTime::Locale - new release for feedback

[Richard Evans]

On Friday 20 Jun 2003 10:38 pm, Dave Rolsky wrote:
> On Fri, 20 Jun 2003, Richard Evans wrote:
> > Dave Rolsky wrote:
> > > On Fri, 20 Jun 2003, Richard Evans wrote:
> > >> I'm looking at one further release before it hopefully goes into CVS
> > >> (will that be ok Dave?), so feedback is more important than ever!
> > >
> > > Is there any reason not to put it in CVS sooner (like now?).  There's
> > > some small tweaks I'd like to make but they're not really worth me
> > > sending you patches for them.
> >
> > There are a few rough edges left, which I know about, and guarantee to
> > have fixed by next weekend (or sooner) - that would definitely be a
> > cleaner release to have as the initial CVS import.
>
> I'm just talking about importing the conversion script, not the end
> result.

Oh - that's going to be a problem. 

The conversion script is a horrible mess - it's part of the other locale stuff 
I was (maybe still am) doing, and uses 10 other modules that are in a state 
of flux ATM. I also have a horrible feeling the ICU .xml file format had 
changed last time I looked at the CVS code.

Based off the glacial response I've got from the openI18N guys - "yeah, that 
looks wrong, we'll fix it" - now one and a half months later and no change 
yet - my gut feeling is that the Locale data should go into CVS as it is now. 

Corrections and additions would then go directly into the DT::Locale CVS 
rather than waiting weeks for fixes to get put into the ICU locales.

But I'm guessing that's not what you have in mind - do you want the DT::Locale 
code as it stands to go in, or are you only really interested in the 
conversion script? If it's the latter, I'll try to get it into a maintainable 
state, but that will take a while longer, no question about that!

Cheers,
-- 
Rich
[EMAIL PROTECTED]

Re: DT::F::Epoch

[John Peacock]

Eugene van der Pijll wrote:
I can't think of a good solution for this. I will at least add a
Math::BigInt prereq to MakeFile.PL, but if I include the latest version
(1.64), it won't build because of the missing file; if I leave out the
latest version, people with v1.64 installed will be annoyed...
Have you informed Tels that the CPAN version is missing a file?  I helped him 
(or more like prodded him repeatedly) develop the newer M::BI.

And all that won't help the 5.00503 users, who can't install the new
Math::Bigints.
I don't remember Tels deciding to abandon the 5.005_03 users.  I seriously doubt 
he did so, since the whole point of updating M::BI on CPAN was to permit 
everyone to be on the same page.  What exactly breaks?

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: Getting different results from DateTime and Manip for epoch time

[Eugene van der Pijll]

John Peacock schreef:
> Eugene van der Pijll wrote:
> >That's TAI64, an epoch count based on the time scale TAI. TAI 64 starts
> >at Jan 1, 1970 (TAI) = Dec 31, 1969 23:59:xx UTC.
> 
> You mean _TAI32_ starts at Jan 1, 1970 (TAI), right?

No I meant TAI 64. It starts in 1970, at v62.0.0.0.0.0.0.0. (Not
every-one starts counting at 0 or at 1...

> nor am I able to find 
> anything useful about TAI at all, except on Dan Bernstein's pages.

There's not much to tell about TAI. It just counts seconds, 60 in a
minute, 3600 in an hour, 86400 in a day, 31536000 in a year (or
31622400, about once every 4 years). That's all you need to know about
TAI.

UT0, UT1, UTC and TT are the tricky time scales.

> 
> I'm sure there is much more useful information listed in the French version 
> of http://www.bipm.org.
> 

Nope.

Eugene

Re: DT::F::Epoch

[Eugene van der Pijll]

Dave Rolsky schreef:
> This fails on both 5.00503 and 5.6.1.

Probably because Math::BigInt lacks an as_hex() method in those
versions. And the TAI64 string value needs this method.

I can't think of a good solution for this. I will at least add a
Math::BigInt prereq to MakeFile.PL, but if I include the latest version
(1.64), it won't build because of the missing file; if I leave out the
latest version, people with v1.64 installed will be annoyed...

And all that won't help the 5.00503 users, who can't install the new
Math::Bigints.

Eugene

Business Dates

[Jesse Shy]

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: ISO 8601 is eeeevil!

[Iain Truskett]

* Ben Bennett ([EMAIL PROTECTED]) [20 Jun 2003 21:57]:
> I will try to have something usable by tomorrow...  I made
> some decent progress last night.

Excellent. May I suggest you don't worry too much about
usable? Once you get it out there (or, rather, in there to
CVS) other people can help work on it =)


cheers,
-- 
Iain.

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

[John Peacock]

Eugene van der Pijll wrote:
That's TAI64, an epoch count based on the time scale TAI. TAI 64 starts
at Jan 1, 1970 (TAI) = Dec 31, 1969 23:59:xx UTC.
You mean _TAI32_ starts at Jan 1, 1970 (TAI), right?  I'm not able to find _any_ 
definition/implementation of TAI32 on the web, nor am I able to find anything 
useful about TAI at all, except on Dan Bernstein's pages.  The website 
http://www.bipm.org is singularly useless, even when compared to other 
international standards bodies.


I'm sure there is much more useful information listed in the French version of 
http://www.bipm.org.


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: Having problems with Datetime-format-Strptime-1.02 install o n Win32

[Hill, Ronald]

Hi Rick,

[snipped]

> 
> Yup, DateTime on CVS won't work. Which reminds me that I need to 
> supply Dave with another patch before he releases the new DateTime.
> 
> [Explaination: DateTime now requires a valid date. Strptime for 
> day-of-year initiates DateTime with a year=>$year month=>1 and 
> day=>$day-of-year]
> 

Well, at least you know about the problem.
I am now in the process of rewritting some perl CGI scripts
and was hoping I could use DateTime instead of the Date-Manip/Calc
modules and right now I need to parse a date!!

What I was going to do was something like this:

my $Strp = new DateTime::Format::Strptime(
pattern => '%e-%B-%Y %T',
language=> 'English',
time_zone   => 'America/Los_Angeles',
);

my $dt = $Strp->parse_datetime('18-jun-2003 10:07:38');

I really need to get a feel for all of the modules out there!!

Thanks Rick!!

Ron Hill

Re: RFC: Fiscal Dates

[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: RFC: Fiscal Dates

[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: Having problems with Datetime-format-Strptime-1.02 install on Wi n32

[Ben Bennett]

Personally I think this is a good reason to either add a new
DateTime constructor or to add the flag that relaxes the parameter
validation and allows rollovers.

  -ben

On Fri, Jun 20, 2003 at 09:12:38AM +1000, Rick Measham wrote:
> At 1:19 PM -0700 19/6/03, Hill, Ronald wrote:
> >I am running the CVS versions of DateTime/DateTime-TimeZone for perl 5.6.1
> >
> >Any thoughts?
> 
> Yup, DateTime on CVS wont work. Which reminds me that I need to 
> supply Dave with another patch before he releases the new DateTime.
> 
> [Explaination: DateTime now requires a valid date. Strptime for 
> day-of-year initiates DateTime with a year=>$year month=>1 and 
> day=>$day-of-year]
> 
> 
> Cheers!
> Rick

Re: ISO 8601 is eeeevil!

[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.

RFC: Fiscal Dates

[Jesse Shy]

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.

FW: Date::Time 0.12

[Ilya A. Tereshchenko]

Hello,
 
I've failed reach Dave Rolsky (some problem with urth.org domain
resolving), so I forwarding to mail list. Hope Dave reads it.
 
   Best regards, Elliot.
 

---
Ilya A. Tereshchenko
Developer
Aurorisoft Inc.
 
E-mail:   [EMAIL PROTECTED]
For more visit   http://www.aurorisoft.com/
 

--- 
-Original Message-
From: Ilya A. Tereshchenko [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 20, 2003 1:11 PM
To: '[EMAIL PROTECTED]'
Subject: Date::Time 0.12
 
Hello Dave,
 
I've tried you most recent Date::Time module (0.12) got from CPAN and
found some problems building it. Here is a list:
1)   Under Win32 'finite' function is called '_finite'. I know, it's
Microsoft feature, but I suppose you can tune your makefile to avoid it
:-).
2)   I don't know if this is related to the same 'finite/_finite'
function, but 4 test have failed on my machine. Here is a log:
t\20infinite...ok 7/36# Failed test (t\20infinite.t at line 48)
# Failed test (t\20infinite.t at line 55)
t\20infinite...NOK 12#  got: '-2147483648'
# expected: '-1.#IND'
# Failed test (t\20infinite.t at line 55)
t\20infinite...NOK 13#  got: '-2147483648'
# expected: '-1.#IND'
# Failed test (t\20infinite.t at line 55)
t\20infinite...NOK 14#  got: '0'
# expected: '-1.#IND'
t\20infinite...ok 19/36# Looks like you failed 4 tests of 36.
t\20infinite...dubious
Test returned status 4 (wstat 1024, 0x400)
DIED. FAILED tests 11-14
Failed 4/36 tests, 88.89% okay
Failed TestStat Wstat Total Fail  Failed  List of Failed

---
t\20infinite.t4  1024364  11.11%  11-14
Failed 1/21 test scripts, 95.24% okay. 4/1369 subtests failed, 99.71%
okay.
NMAKE : fatal error U1077: 'C:\Perl\bin\perl.exe' : return code '0x2'
Stop.
 
Hope you can say something about these problems.
 
   Best regards, Elliot.
 
P.S.: Also, I've built your module third time and third time wonder why
don't you assemble all DateTime-LeapSecond, DateTime-TimeZone and
DateTime itself into one module? :-)
 
 

[rfc] DateTime::Util

[Joshua Hoblitt]

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

--

Re: ISO 8601 is eeeevil!

[Joshua Hoblitt]

> I haven't worked on this since the beginning of April.  I believe this is most of 
> the date specifications - not including the week formats.  Week and UTC offset 
> handling, time formats, and date + time formats are left (actually shouldn't be that 
> bad).  Although I don't remember why I stopped working on this.

Actually the time formats can be skipped until DT::Time comes into existence.  The 
date + time + offset formats are simple... should be something like the pasted code.  
The week stuff still has to be handled thou.  hmmm...

-J

--
{
#MMDDThhmmss
#-MM-DDThh:mm:ss
regex => qr/^ (\d{4}) -??  (\d\d) -?? (\d\d) T (\d\d) :?? (\d\d) :?? (\d\d) 
$/x,
params => [ qw( year month day hour minute second ) ],
extra => { time_zone => 'floating' },
},
{
#MMDDThhmmssZ
#-MM-DDThh:mm:ssZ
regex => qr/^ (\d{4}) -??  (\d\d) -?? (\d\d) T (\d\d) :?? (\d\d) :?? (\d\d) Z 
$/x,
params => [ qw( year month day hour minute second ) ],
extra => { time_zone => 'UTC' },
},
{
#MMDDThhmmss+hhmm
#-MM-DDThh:mm:ss+hh:mm
regex => qr/^ (\d{4}) -??  (\d\d) -?? (\d\d) T (\d\d) :?? (\d\d) :?? (\d\d) 
(\+\d\d :?? \d\d) $/x,
params => [ qw( year month day hour minute second time_zone ) ],
postprocess => \&_normalize_offset,
},
{
#MMDDThhmmss+hh
#-MM-DDThh:mm:ss+hh
regex => qr/^ (\d{4}) -??  (\d\d) -?? (\d\d) T (\d\d) :?? (\d\d) :?? (\d\d) 
(\+\d\d) $/x,
params => [ qw( year month day hour minute second time_zone ) ],
postprocess => \&_fix_2_digit_offset,
},

Re: Jalali Calendar

[Ahmad Anvari]

Hello Eugene, Joshua && list,
 
The calendar that is used today has 30, 31 and 29
days. I picked Date::Jalali since it was called Jalali
in the original algorithm and documents. 

Iran uses a calendar of its own which is slightly more
exact than the Gregorian calendar. The present Iranian
calendar, also called the Jalali calendar, dates back
to the eleventh century, when Jalal-ed-din Malek Shah
Seljuq commissioned a panel of scientists in 1074-1079
AD to create a calendar more accurate than those in
use at the time. (more on the calculation at
http://scienceworld.wolfram.com/astronomy/IranianCalendar.html)

I would suggest registering DateTime::Calendar::Jalali
for now. We can always mention that it's also called
Persian according to such and such documents.


_Ahmad

--- Eugene van der Pijll <[EMAIL PROTECTED]> wrote:
> Joshua Hoblitt schreef:
> > > It looks like the Jalali calendar is also called
> the Persian calendar,
> > > so DateTime::Calendar::Persian is a possibility
> too. I'm not familiar
> > > with this calendar, its most common name, and
> the way it is used, so you
> > > (Ahmad) should judge for yourself what name
> would be best.
> > 
> > In Calendrical Calculations it says the Jalali
> calendar used 30 day
> > months while the Persian calendar used 29,30, and
> 31 day months.
> 
> According to
> http://www.projectpluto.com/calendar.htm#jalali ,
> the
> Jalali calendar uses 31, 30 and 29 days. There are
> probably several
> versions of the Persian calendar, some, all or none
> of which are called
> the Jalali calendar...
> 
> That's why I can't tell what the correct name would
> be for this
> calendar, (and why you can't either, I presume).
> Ahmad is hopefully more
> familiar with how the calendar is used today.
> 
> Eugene


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

Re: Having problems with Datetime-format-Strptime-1.02 install on Wi n32

[Rick Measham]

At 1:19 PM -0700 19/6/03, Hill, Ronald wrote:
I am running the CVS versions of DateTime/DateTime-TimeZone for perl 5.6.1

Any thoughts?
Yup, DateTime on CVS wont work. Which reminds me that I need to 
supply Dave with another patch before he releases the new DateTime.

[Explaination: DateTime now requires a valid date. Strptime for 
day-of-year initiates DateTime with a year=>$year month=>1 and 
day=>$day-of-year]

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: All you astro people (and math freaks)

[Rick Measham]

Rick Measham schreef:
 In his question, he assumes that each period (night/day) should be
 evenly divided into 12 parts. However this stinks to me! Surely in
 the middle of winter, the hour before sunrise shouldn't be a heap
 longer than the hour after? Surely the lengths of hours should slowly
 decrease towards noon and then increase again towards midnight. I
 > figured this is a sine wave.
At 9:39 PM +0200 19/6/03, Eugene van der Pijll wrote:
That would perhaps be nicer for us computer-owning people, but that
wasn't how it was implemented in ancient times. It is really much easier
to have only two different hour lengths per day. You only need two
different clepsydras that way.
Sorry, I should have said that I wasn't interested in the historical 
context for this, only in the mathmatics behind it. I realised that 
historically they wouldn't have done what I was suggesting, but as 
you say, for us computer owning people it would be nice.

Sorry for the confusion

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