On Wed, 30 Jul 2003, Joshua Hoblitt wrote:
- For this release, at least, the module always uses Dynaloader. This
is in order to see if this fixes a problem on Solaris where the
install library version of the DateTime .so file is loaded instead of
the newly compiled version in the
0.1502 2003-07-31
[ BUG FIXES ]
- XSLoader wasn't the problem on Solaris, so it's back.
- Now loading the XS version of DateTime.pm is wrapped in an eval
block. If it fails with an error about the object version not
matching, the pure Perl version is loaded instead. This should fix
Solaris.
On Tue, 29 Jul 2003, Dan Sully wrote:
0.13 2003-05-05
[ IMPROVEMENTS ]
- DateTime now does more validation of parameters given to
constructors and to the set() method, so bogus values like a month of
13 are a fatal error.
I'm not entirely sure I'd call this an improvement.
This
On Tue, 29 Jul 2003, Dan Sully wrote:
* Dave Rolsky [EMAIL PROTECTED] shaped the electrons to say...
my $dt1 = DateTime-new( month = $month, year = 2002 );
my $dt2 = $dt1-clone-add( months = 1 )-subtract( seconds = 1 );
There are several variations on the above that'd work.
Which
On Tue, 29 Jul 2003, Dan Sully wrote:
* Dave Rolsky [EMAIL PROTECTED] shaped the electrons to say...
Well, obviously this is a bug in the DateTime code, as that's not what
_anyone_ would expect as a result, right?
Just checking to make sure that I'm not the only anyone here. =)
Ah, looks
0.15 2003-07-29
[ IMPROVEMENTS ]
- The utc_rd_values() method now returns nanoseconds in addition, Rata
Die days and minutes. Based on a patch by Joshua Hoblitt.
- The from_object() method expects objects to return the same values
from their utc_rd_values() methods. Based on a patch by
On Tue, 29 Jul 2003, Joshua Hoblitt wrote:
'DateTime' Object
http://www.python.org/doc/2.3/lib/module-datetime.html
No leap seconds. Years 1 - only! (why?!). microsecond resolution.
Gregorian Calendar from Calendrical Calculations that requires 'DateTime'
On Mon, 28 Jul 2003, Rick Measham wrote:
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Joshua Hoblitt) wrote:
I'd fix DT::F::Strptime but Rick won't put his code into our CVS tree.
I meant to say hasn't - sorry Rick.
Dave, if you want to add me to the CVS stuff I'll see if I can
On Sun, 27 Jul 2003, Joshua Hoblitt wrote:
A while ago I proposed a patch that would add rd_nanosecs to the
return values from utc_r_values(). If I recall correctly, I was
supposed to update the calendar dev docs before applying the patch.
This would avoid the need for every calendar to
On Sun, 27 Jul 2003, Joshua Hoblitt wrote:
I'm tempted to just die if both objects aren't DateTime.pm objects
actually. I'd like to be free to optimize this method in the future, and
I don't want to have to support other classes in it.
And if there is a real need, a
On Sun, 27 Jul 2003, Joshua Hoblitt wrote:
Why don't you go ahead and update the calendar dev docs too. Since if
nothing is returned for nanoseconds it'll be zero (well, undef), the
transition shouldn't be a problem
Should we guarantee (well specify anyways) that value passed/returned
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
On Fri, 25 Jul 2003, Joshua Hoblitt wrote:
I've reinstalled just about everything applicable from CPAN. I wonder
if it's a problem with some c library in the dep. chain.
Note that XML::Simple uses XML::SAX, which in turn picks one of
XML::Expat, XML::SAX::PurePerl, or XML::LibXML to do
On Fri, 25 Jul 2003, Joshua Hoblitt wrote:
I've reinstalled just about everything applicable from CPAN. I wonder
if it's a problem with some c library in the dep. chain.
Note that XML::Simple uses XML::SAX, which in turn picks one of
XML::Expat, XML::SAX::PurePerl, or XML::LibXML to
On Thu, 24 Jul 2003, Serge Leger wrote:
The call to DefaultLocale should only occur when it is needed (ie: just
before actually validating the parameters). After having looked at where
BasicValidate and NewValidate are used, I have applied the following
changes to the new function:
Yep,
On Fri, 25 Jul 2003 [EMAIL PROTECTED] wrote:
I'm trying to figure out how to allow for incomplete year/month/day,
year/week/day, or year/day in DT::I.
One way is to have a separate implementation for each case:
DateTime::Incomplete
year / set_year
month / set_month
day / set_day
Got some weird failures on Solaris and realized the hopelessness of
depending on external stuff.
1.07_92 2003-07-23
- Removed tests which relied on the zoneinfo database to be up to date
and accurate in order to pass, since we have absolutely no control
over this whatsoever. I hate external
On Wed, 23 Jul 2003, Joshua Hoblitt wrote:
You'll have to generate the locale files from the icu-xml descriptions
(instructions are in the dist). Or if you wait about a week DT::Locale
will hopefully be released to CPAN (crosses arms, looks at Dave).
Poof, done.
/*===
Not terribly exciting by itself, but look for DateTime.pm 0.14 coming
soon, which will make use of this.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Well, here goes nothing ...
Still need to get to the root of the infinite number problems of Win32.
Volunteers wanted ...
0.14 2003-07-23
[ BACKWARDS INCOMPATIBILITIES ]
- The DateTime::Language modules are no longer being developed or
distributed as part of the DateTime.pm distribution.
Again, test results on non-UNIX platforms are appreciated.
1.07_93 2003-07-23
- Henrik's code explicitly didn't work with negative epoch values,
which is not good. Now we assume that they are allowed, except on
MacOS, which is known to use an unsigned int for time_t.
- Document that dates
On Wed, 23 Jul 2003, Ben Bennett wrote:
I hate to say this but the language stuff may be deprecated in favor
of locales...
But if you are willing to convert this to a locale definition I would
like to ask you about some extra stuff for my DateTime::Format::Common
parser. But I am not quite
On Wed, 23 Jul 2003, Ricardo SIGNES wrote:
Is there a good way to determine whether to not to return Unicode
strings? That's what I'm doing now, but obviously it's not so nice at
the console. I don't do much serious work with Unicode in Perl, and
there might be an obvious solution I don't
On Tue, 22 Jul 2003, Ben Bennett wrote:
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
Testing on non-UNIX platforms is much appreciated. Any Mac Classic users
out there?
1.07_91 2003-07-22
- Henrik refined his edge case fix to work on Win32, which apparently
dislikes large negative signed ints. Tests now pass on Win32. More
testing on other platforms is appreciated.
-
On Sun, 20 Jul 2003, Joshua Hoblitt wrote:
Did anyone contact the author (Blair Zajac) about renaming this module?
Nope, but it'd be nice if he did.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
The existing code has some serious problems with the use of the base
datetime.
For example, the set() method will attempt to unconditionally call set()
on the base object. But if the base is 2003-02-10T00:00:00 and one calls
$dti-set( day = 30 ) then we'll get a validation error. But if the
On Mon, 21 Jul 2003, Flavio S. Glock wrote:
I'd like to have this in DateTime:
set( time_zone = $tz );
You mean as opposed to set_time_zone?
set( locale = $loc );
This already exists;
get( time_zone/locale/year/month/etc );
# returns a number or an object
get_str(
On Mon, 21 Jul 2003, Joshua Hoblitt wrote:
DateTime::TimeZone::Local::_from_etc_timezone needs to be modified for
Solaris. Is there a perfered way of doing this? I can either check the
osname then decided what path to execute or just always check for
/etc/TIMEZONE.
The latter. I'd assume
On Mon, 21 Jul 2003, Flavio Soibelmann Glock wrote:
has(), get()
I really dislike this API. The object should look as much like a
DateTime.pm object as possible. For other calendars, we can come up with
some clever way to auto-generate appropriate classes for them, if that's
necessary. But I
On Sun, 20 Jul 2003, Claus Färber wrote:
The most important difference is that I'd like DateTime::Incomplete to
actually BE a DateTime: Methods defined by DateTime would just behave as
if the base date had been set to 1970-01-01T00:00:00.00...; new methods
(or parameters) would make up the
On Wed, 16 Jul 2003, Joshua Hoblitt wrote:
./tools/generate_from_icu --dir icu-xml
Reading ICU files from: 'icu-xml'...
af
af_ZA
And then it hangs indefinitely. Any ideas?
Upgrade XML::Simple and/or maybe install the latest XML::SAX. I think
it's the XML parser hanging.
-dave
On Thu, 17 Jul 2003, Nick Porter wrote:
I really want to play with this module but I just can't get the thing to
make. I'm no guru or coder I just muck about with perl so working out how to
install DateTime-0.13 into ActivePerl using CPAN was an effort in itself.
I've got all the dependencies
On Thu, 17 Jul 2003, Joshua Hoblitt wrote:
Upgrade XML::Simple and/or maybe install the latest XML::SAX. I think
it's the XML parser hanging.
Already upgraded both - didn't fix it. It feels like the parser has a race
condition.
Also upgrade XML::Parser, just for fun.
-dav
Can someone tell me what the _local_ time is for TZ changes in Sydney? My
reading of the time zone file suggests that on the last Sunday in March,
at _1:00_ (AM) local time, the clock is moved one hour back, and that on
the last Sunday in October, at _2:00_ (AM) local time, the clock is moved
On Wed, 16 Jul 2003, Iain Truskett wrote:
What do people think parsers should return if they can't
parse? And what if they do parse, but DateTime doesn't want
to create an object of the appropriate specification?
Should we wrap our methods in evals and return undef?
Should we just throw
On Wed, 16 Jul 2003, Rick Measham wrote:
At 3:42 PM +1000 16/7/03, Iain Truskett wrote:
What do people think parsers should return if they can't
parse? And what if they do parse, but DateTime doesn't want
to create an object of the appropriate specification?
DateTime::Undef :)
If all
On Wed, 16 Jul 2003, John Siracusa wrote:
Here's my take on handling parse errors, and error handling in general.
1. I don't like to (unconditionally) die from within libraries except for
conditions that are totally avoidable. For example, I die if you forget to
send a required argument.
On Tue, 15 Jul 2003, Joshua Hoblitt wrote:
2. My option:
$day_of_month = STDIN;
$dt-set( day = $day_of_month )-truncate( to = 'day' );
print Your day must be a number in the current month if
$dt-is_undef;
See, most people won't _bother_ with the 3rd line in option 2!
On Tue, 15 Jul 2003, Joshua Hoblitt wrote:
We were talking about returning DT::Undef objects from parsers. So, for
example, if the _format_ being parsed _defines_ an unknown or undefined
date/time an object can be returned that reflects this. Simply
returning undef when an object is
On Wed, 16 Jul 2003, Joshua Hoblitt wrote:
Pheonix
First of all, it's Phoenix, and second of all, you're thinking of
Firebird. Don't get that name wrong or they'll come down on you like a
ton of bricks ;)
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
On Wed, 16 Jul 2003, Eugene van der Pijll wrote:
But no part of DateTime, the base module, should return these non-dates.
They should only be a result of some action where it makes sense that
something else than a date is returned.
Specifically, the default parser should not return these
On Tue, 15 Jul 2003, Rick Measham wrote:
Will this be useful to anyone other than me?
Yes, I think it's somewhat useful for end users and definitely useful
other module authors.
Is there a better name?
I sure hope so, because I _really_ don't want to see something called
DT::Event::DT on
If people on non-Unix platforms could try this out I'd be quite grateful.
I'm especially interested in hearing from Win32 and Mac users. Also, if
anyone has a platform where time_t is not a 32-bit int, that'd be another
interesting place to test.
1.07_90
- Fixed behavior for edge cases like
On Tue, 15 Jul 2003, Ben Bennett wrote:
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
On Tue, 15 Jul 2003, Ben Bennett wrote:
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.
Actually, I was thinking that this would be done when
On Tue, 15 Jul 2003, Ben Bennett wrote:
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
On Tue, 15 Jul 2003, Ben Bennett wrote:
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_
On Mon, 14 Jul 2003, Rick Measham wrote:
Maybe an example will explain why I want to have an undef DateTime:
print $natural-parse_datetime(Feb 29th, this year)
-set( day = 31 )
-add( days = 12)
-datetime;
Of course, this won't always work because:
1. the string Feb 29th
On Mon, 14 Jul 2003, Hill, Ronald wrote:
On Sunday, July 13, 2003, at 08:11 PM, Iain Truskett wrote:
Remember: part of the point of having the various format
modules is that you can pick'n'mix. You could conceivably
wrap a number of them in Builder to make your own parser
that
On Mon, 14 Jul 2003, John Siracusa wrote:
On 7/14/03 1:05 PM, Dave Rolsky wrote:
Anything called DT::F::Simple should parse everything Date::Parse can
parse, at least, and not _too_ much more, because it should also be
reasonably fast ;)
Great, but the $64K question is: do we then get
On Mon, 14 Jul 2003, John Siracusa wrote:
That is another reason why I suggest not having the parser() and parse()
methods in DT at all. For people who never need to parse random date strings,
they only use DateTime; and they are done; everyone else does use
DateTime::Format; as well.
On Mon, 14 Jul 2003, Flavio S. Glock wrote:
On Sun, 13 Jul 2003 [EMAIL PROTECTED] wrote:
It would be easy to change the Perl code generator into a C code
generator. Then you could use DT::LeapSecond at compile time, if they
are using XS, or at runtime, if they are using pure Perl.
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
On Mon, 14 Jul 2003, Joshua Hoblitt wrote:
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.
I usually think of ::Simple as referring to a reduced interface. Maybe
::Basic is a better namespace.
I like ::Common,
On Sat, 13 Jul 2003, Rick Measham wrote:
On Sat, 12 Jul 2003, Ben Bennett wrote:
Does it understand 1/3/2003? If so, how does it resolve the day and
month ambiguity?
On Sun, 2003-07-13 at 12:46, Dave Rolsky wrote:
Ideally, it'd be an attribute of the locale. I bet we could figure
On Sun, 13 Jul 2003, Rick Measham wrote:
On Sun, 2003-07-13 at 17:09, Dave Rolsky wrote:
Now I'm confused. Are you proposing that there be a language parameter
_and_ a locale parameter?
Hmmm .. well I was going to make it a case of 'use one or the other',
but on second thoughts that's
On Sun, 13 Jul 2003 [EMAIL PROTECTED] wrote:
It would be easy to change the Perl code generator into a C code
generator. Then you could use DT::LeapSecond at compile time, if they
are using XS, or at runtime, if they are using pure Perl.
But the point is to avoid having to cross the Perl-C
On Sun, 13 Jul 2003, Joshua Hoblitt wrote:
Oh, and while we're at it, can there be any way to set an undefined
datetime object constructor:
$undef = DateTime-undef();
If Dave OKs this it should be a separate class. Probably DT::Undef.
If Dave OKs? Does that ever happen.
I recently checked in the DT::Locale code to SF CVS. Just now, I also
checked in the changes necessary to make DateTime.pm use it. It seems to
work quite well, from my limited testing.
There's a couple more things I want to do before a release:
- Decide how to handle default format length.
Why is the directory called DateTime-Event-NameDay-0.02? Ben, can you ask
SF to change this, please?
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
On Sat, 6 Jul 2003, Rick Measham wrote:
On Sun, 2003-07-06 at 09:27, Matt Sisk wrote:
I was terming a 'clock' as anything with periodicity. An 'unbounded' clock would
be a clock without an associated epoch or starting date.
A clock without context still has characteristics and can be
On Thu, 3 Jul 2003, Jesse Shy wrote:
Yes, please, tell me what to change. I dont know what it should have been.
I looked at the date time module and the DateTime-TimeZone modules for
examples and read the standards from the web site. So I used named
parameters, did I miss something that
On Fri, 4 Jul 2003, Flavio S. Glock wrote:
Joshua Hoblitt wrote:
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).
Ok, how about this for DT::Duration:Set:
Can you and/or Joshua explain what this would be used
On Fri, 4 Jul 2003, Joshua Hoblitt wrote:
That's all correct, and the implementation is
cut-and-paste DT::Set/DT::E::Recurrence code.
Well I have it strait in my head now. :)
Dave wants to know _why_ we want this!
ISO8601 recurring time intervals.
And what _are_ these, and what do
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.
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
On Thu, 3 Jul 2003, Jesse Shy wrote:
I think I got everything up that is needed.
I want to change the API a bit, to be more like the other DT modules.
Right now it's not even close to the other modules.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
On Thu, 3 Jul 2003, Ben Bennett wrote:
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?
Probably for unambiguous cases
On Thu, 3 Jul 2003, Flavio S. Glock wrote:
On Thu, 3 Jul 2003, Flavio Soibelmann Glock wrote:
$base_set-{set}{as_ical} = [ uc('recur:'.$recur_str) ];
Dave Rolsky wrote:
use a subclass of DateTime::Set.
Ok, I think it might work. How about the module name?
Is this ok?
DateTime
On Tue, 1 Jul 2003, Hill, Ronald wrote:
You can do ./Build dist. The latest Module::Build beta
(0.18_02) also
I tried this. Here is the result.
Creating DateTime-TimeZone-0.21.tar.gz
Can't locate object method create_archive via package Archive::Tar at
F:\pe
ild/Base.pm line 1323.
On Tue, 1 Jul 2003, Joshua Hoblitt wrote:
Agreed. I think it should boil down to recurrences and durations.. If
most people need that functionality then lets call your module
DT::F::ISO8601 and I'll use ISO8601::Simple. If they don't then I'll
take ISO8601 and you can use ISO8601::Complex.
On Sun, 29 Jun 2003, Joshua Hoblitt wrote:
I just noticed your on MJD's lightning talk list for OSCON. What are
you going to cram into 5 minutes? :)
Um, I dunno. I figured I'd write it that day or something. I'm mostly
planning on just telling people what the project is and why it's a good
On Mon, 30 Jun 2003, Ben Bennett wrote:
The nits:
1) The following doesn't work because add_duration() doesn't return
the object, but rather falls through and returns the number of
nanoseconds in the final object:
--
my $dur = DateTime::Duration-new(months = 3)-add(hours = -3);
On Mon, 30 Jun 2003, Flavio S. Glock wrote:
Well, maybe. Right now the constructor is really simple, which is good.
More functionality is nice, but so is simplicity.
use DateTime;
my $dt = DateTime-now;
my $dur = sub { $_[0]-add( months = 3 )-subtract( hours = 3 ) };
print
On Mon, 30 Jun 2003, Ben Bennett wrote:
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 ) +
On Mon, 30 Jun 2003, Matt Sisk wrote:
So, yes, the implication is that:
$dur = DT::Dur-new(days = 2, months = -1);
would indeed behave differently than:
$dur = DT::Dur-new(months = -1, days = 2);
So long as the behavior (intrinsic to durations) is well documented I think it
stands
On Mon, 30 Jun 2003, Matt Sisk wrote:
Found the parse_recurrence docs in the CVS, thanks.
However, there's a good reason the format_recurrence method is not
documented...it doesn't exist.
Are there plans to implement this?
This is hard, since recurrences are implemented as
On Mon, 30 Jun 2003, Joshua Hoblitt wrote:
Why not:
$dur1 = new DT::Dur( days = 2 );
$dur2 = new DT::Dur( months = 1 );
$dur3 = $dur1 - $dur2;
$dur3-add( days = 3 );
If you add $dur3 to a date, it would add 2 days and
subtract a month, then add 3 days again.
This is not too
On Sat, 28 Jun 2003, Joshua Hoblitt wrote:
I received this bug report on one of my modules. Is this a known
problem with Module::Build or nmake?
Module::Build doesn't use make, so instead of nmake test you need to do
./Build test or .\Build test.
-dave
/*===
House
I thought that this was going to be the parent namespace, not the actual
module name, right?
I don't think we should co-opt the whole namespace for a module which just
provides a few simple pieces of functionality.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
On Sat, 28 Jun 2003, Rick Measham wrote:
This is just for comment. As per my previous email, this module allows
one to compare durations when given a reference point. I'm not real
happy with the method names, and I've just called it
DateTime::Duration::Compare for the time being.
On Sat, 28 Jun 2003 [EMAIL PROTECTED] wrote:
# Failed test (t/01datetime.t at line 87)
# got: 'TZID=-0100:19000101T15'
# expected: '19000101T16Z'
# Looks like you failed 1 tests of 37.
my $dt = DateTime-new(
year = 1900, hour = 15, time_zone = '-0100' );
On Fri, 27 Jun 2003, Flavio S. Glock wrote:
You could use the name DateTime::File::Ics
or DateTime::File::ICal
What would the DT::File namespace be for? I don't want to arbitrarily add
new namespaces.
This sounds to me like two modules: DT::Format::ICS and DT::Event::ICS.
-dave
On Thu, 26 Jun 2003, Flavio S. Glock wrote:
yet another object = slower program
At least for DateTime.pm, I think this is enough for me to not use it.
Given the fact that the internals work fine now, I don't see a good reason
to change them.
It seems to me that converting between calendars
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
0.21 2003-06-25
- Switched to Module::Build, which should fix the installation
problems caused by very long Makefile lines on some platforms.
- Fixed a bug in finding the correct data for a given datetime. This
could occur when calling set_time_zone on an object that was very
close to a DST
Ugh, my release management skills stink. Hopefully there won't be another
release with this many changes at once for a _long_ time (or better yet,
never!).
I gave up on Win32 and made a hack to skip the failing test. I figure
that the infinite datetime stuff is marginal enough that it's better
On Mon, 23 Jun 2003, Joshua Hoblitt wrote:
I think you probably never got the original email with this patch (it
was sent while you reported having difficulties). The general idea was
to do something like the following and then update the calendar docs so
nanosecond precision is always
On Fri, 20 Jun 2003, Joshua Hoblitt wrote:
DT::TZ::LINKS is still the only internal structure that is modified.
Yes, but you access @DT::TZ::ALL as well.
almost certainly does not belong in a module called Alias! Why does
it
Probably not - but what ever module handles the aliasing
On Sat, 21 Jun 2003, Bruce Van Allen wrote:
One thought: A fiscal year is type of calendar, and as the (long-ago)
DT consensus was that all calendars are adopted fictions, perhaps it
should be DT::Calendar::FiscalYear. The API would have to be somewhat
different from the existing DT::C
On Sun, 22 Jun 2003, Ben Bennett wrote:
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).
If it was on Thursday and Friday it was still following the Gregorian
calendar though. That was my basic
On Sun, 22 Jun 2003, Joshua Hoblitt wrote:
Should I add the namespaces doc to web/htdocs/developer/?
Sure, please do.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
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
On Sun, 22 Jun 2003, Richard Evans wrote:
* Added new locale generator (ICUGenerator.pl) which is not derived from my
other work - this is largely untested. Locale data is not supplied and must
be generated from ICU .xml sources.
Thanks, this looks great.
* All manually edited code removed
On Sun, 22 Jun 2003, Ben Bennett wrote:
Check out Dave's work on the POD to HTML stuff for the FAQ for a
start...
Actually, the FAQ is much more complicated. For the other docs I've just
been doing
perl -MPod::Simple::HTML -e \
Pod::Simple::HTML-filter(shift) \
pod file
and then
On Sat, 21 Jun 2003, Joshua Hoblitt wrote:
DT::TZ::LINKS is still the only internal structure that is modified.
Yes, but you access @DT::TZ::ALL as well.
I was necessary to verify that what an alias was pointing to was valid.
Once the dependency was already there I implemented the rest.
On Sat, 21 Jun 2003, Joshua Hoblitt wrote:
There is a DateTime-from_day_of_year constructor.
In the CVS version - what is the ETA for the next release?
The only thing I've been waiting on for a while is a resolution of the
Win32 problems. If we can't find a proper fix very soon (like by
On Sat, 21 Jun 2003, Jesse Shy wrote:
Maybe I should include my ugly little hack for Data::Calc and how I am
employing it an a live application?
Please do. I think that basing what we start with on existing, in-use
code, is definitely a reasonable idea.
While I know that DateTime::Business
On Mon, 9 Jun 2003, Joshua Hoblitt wrote:
Here is a small patch that allows you to create a DT::Language object by
just calling new on it (and thus not being trapped into the DT::Language
namespace).
This should tie me over until locale is officially released. :)
You'll be happy to know
701 - 800 of 1076 matches
Mail list logo
