> The day_of_week() method DOES NOT TAKE ARGUMENTS!
I wonder if it's worth the overhead of checking for extraneous parameters on all
methods?
-J
--
Hi Ron,
I'm a bit confused by your parameters to day_of_week().
This is the actual implementation from DateTime.pm
sub day_of_week { $_[0]->{local_c}{day_of_week} }
-J
--
> script=
>
> use strict;
> use warnings;
> use DateTime;
>
> my $dt =
It's defined in the docs...
=item * %V
The ISO 8601:1988 week number of the current year as a decimal number,
range 01 to 53, where week 1 is the first week that has at least 4
days in the current year, and with Monday as the first day of the
week. See also %U and %W.
'U' => sub { my $dow
I was taking a look at what's currently in Redhat's 'Rawhide' and I discovered that
DateTime 0.17 has test failures on their 5.8.1 RC4 build.
-J
--
Running make test
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0,
'blib/lib', 'blib/arch')" t/*.t
t/00load..
> Let me know what I can do, what has been, done, or if I should just sit an
> watch for a while!
You can read our documentation at http://datetime.perl.org/.
The modules, developer, and FAQ sections are key reading.
-J
--
On Thu, 4 Sep 2003, Dave Rolsky wrote:
> On Thu, 4 Sep 2003, David Wheeler wrote:
>
> > > It's probably that simple. Simply setting the TZ env var probably
> > > won't
> > > do much. An app has to call POSIX::tzset() for that take effect.
> >
> > I find that for most date and time handling I do,
> Ok, I'm convinced. Just go ahead and check it in as implemented.
Done. I'll also add some tests for the 'name' normalization in OffsetOnly before the
next release.
-J
--
> I didn't look up the offset for Kiribati, actually, so thanks for the
> correction.
I think the republic crosses at least 4 timezones.
> Offsets of more than 12 hours aren't that strange; countries near the
> international date line can choose on which side of that line they are.
> I wouldn't b
> Anyone have any idea why this might fail on Linux?
Was it the perl build that shipped with Mandrake? Can he give us the perl -V?
-J
--
> > There's no official limit on offsets are there? I can envision some
> > small country declaring an offset of greater then 24hours.
>
> You can? That doesn't make much sense to me. If it happens, we can
> change the code ;)
The universe doesn't always make sense to you? :) I choose 99:59:59
> > The only problem is that DT::subtract_datetime doesn't use it. It
> > probably should. (It would be even better if there was an option to
> > calculate the difference in days & secs. But the default should probably
> > be to return a difference of months, days, minutes, seconds.)
>
> I think th
> Cuba (-0500) was at some point planning to change to +1900, to be the
> first country in the year 2000. If that would have happened, what do you
> think Kiribati (+1200, the first country to celebrate 2000 in reality)
> would have done? (They would have gone to +3600, of course; and perhaps
> eve
> The infrastructure does exist: a DT::Duration can contain years
> (actually, it contains months; but the conversion months <=> years is
> unique), and a DT of say 2 years and 3 months already is relative to
> DateTime.
>
> The only problem is that DT::subtract_datetime doesn't use it. It
> probab
> Can you change it so that the maximum offset is 24:00:00 and then check it
> in?
There's no official limit on offsets are there? I can envision some small country
declaring an offset of greater then 24hours.
-J
--
This patch started out as just adding some tests (taken from DT::TZ::Alias) but I
uncovered several issues.
These currently accepted offset formats should be rejected as they are ambiguous:
'111', '+111', '-111',
'1:11', '+1:11', '-1:11',
'1', '+1', '-1',
'111:11', '+111:11', '-111:1
> Again I fail to see the logic or even value in the DateTime::Duration
> behaving as above. But, I'm sure I'm probably just missing something
> important.
Durations are independent of dates and times.
> The only one that does makes since is Deltas but only
> because it is returning a hash that h
Hi Mattew,
> $birth=DateTime->new(year=>1968,month=>6,day=>28);
> print $birth->ymd."\n";
> $today=DateTime->today;
> print $today->ymd."\n";
> $age=$today-$birth;
> print $age->years."\n";
$age is a DateTime::Duration object. Unfortunately math with these object can be a
little non-intuitive.
> I wonder if we shouldn't make preserve the default EOM mode when the
> duration is negative?
Sounds reasonable. It's probably worthy of a FAQ entry as well.
-J
--
> > How about moving the pure-Perl DT::LeapSecond to DateTime.pm/ ?
>
> Seems like a good idea. Do you want to do it or should I?
I'd like to keep it separated. I believe it maybe useful outside the context of DT.
-J
--
> On the one hand, I agree. "HiRes" is bad, and "hires" is a bit worse.
> OTOH, _so_ many people are already familiar with Time::HiRes, that having
> our own variation on it may be confusing to as many people, or more, as
> "hires" is.
So are we back to DT::HiRes? Or just rename the constructor?
> > DateTime->now( time_zone => 'local' );
>
> It already works this way.
See what happens when I read my email before morning coffee. :)
-J
--
> > So are we back to DT::HiRes? Or just rename the constructor? I would
> > like to see this functionality make it into the next release.
>
> I guess sticking it in a separate module DateTime::HiRes works, since that
> way we don't force people to load Time::HiRes if they don't need it.
What ab
> If you only have a year and day of year, then having a from_day_of_year
> constructor saves a _lot_ of calculation that end users have to do. OTOH,
> having to do 'DateTime->now(time_zone => "local")' isn't very onerous at
> all.
If you need an example DT::F::ISO8601 makes heavy use of from_day
> What I want is the reverse of what alias does. Or rather I'd like
> timezone to remember what value it was created with. If I create an
> alias 'EST' => 'UTC' and then create a datetime with 'EST', I'd like to
> get EST as the name rather than UTC.
Awww - I understand what your asking for now.
> Maybe there should be an extra accessor ->link_name. (They're called
> links in the TimeZone innards). Then when ->time_zone_short_name is
> called and it has no value, it return ->link_name. Same for long_name.
I don't like that at all. You really should be creating new classes with your
spec
> Okay, so maybe a new constructor then? DateTime->localtime()? Getting
> the current local time seems more common than, say, constructing a
> DateTime object from a day of the year, IMO :)
We have enough constructors as it is. I could be talked into:
DateTime->now( time_zone => 'local' );
Bu
Hi Ron,
Here is a 'eating our own dog food' patch against Astro::Sunrise 0.8. :)
Cheers,
-J
--
diff -ur Astro-Sunrise-0.8/Makefile.PL Astro-Sunrise-0.8.new/Makefile.PL
--- Astro-Sunrise-0.8/Makefile.PL 2003-02-27 05:05:20.0 -1000
+++ Astro-Sunrise-0.8.new/Makefile.PL 2003-08-06
> I think a constructor aimed at time_zone => 'local' makes sense. If not
> that, then perhaps a class variable for DEFAULT_TIMEZONE or somesuch.
DateTime->now( time_zone => 'local' );
vs.
DateTime->local_now;
Saves an incredible 18 characters even with generous spacing.
> Also, regarding the is
> So there's nothing that relies on a TimeZone module being
> DateTime::TimeZone? If not then surely we should make Alias the same?
> Just a thought.
DT::TZ::Alias doesn't know _anything_ about namespaces. It is wholly dependent on
DT::TZ.
-J
--
> While I'm thinking of it, I'd like to be able to set names and
> short-names for offsets. I have a list of short names in Strptime, but
> I've love to be able to get these back from TimeZone somehow. Just like
> we do with Olsen (or is it Olson, one's the twins, one's the time, can't
> ever remem
> : I was recently doing lots of virgin builds and noticed a faulty
> : dependency being triggered:
> : DateTime::Format::Builder -> DT::F::Strptime -> DT::Language
> :
> : This fails since some of those are no longer on CPAN.
>
> Yes, and therefore also breaks the beta version of Time::Piece beca
> > Anyway, does this API sound sane? And if it does, anyone have any really
> > clever implementation ideas? I have some scary ones involved AUTOLOAD and
> > constructing classes on the fly.
>
> help me understand it -
> Does something like DT::Incomplete could be a wrapping class?
No. This is
> > A solution that is more or less equivalent, is to change the
> > DefaultLocale routine. [...]
> > Probably this changes the behaviour if the default locale is aliased.
> > But IMHO, that's probably for the better.
>
> Yeah, that was my concern: add_aliases() and friends in
> DateTime::Locale wo
> I suspect updates to it will be quite infrequent, though. Other than new
> leap seconds, why else would it change?
I hadn't read ahead in my email. I was concerned about the functionality being
folding into the DT namespace and the DT::Leapsecond interface disappearing. That
didn't happen s
> > > I would find this handy if we could do something like that :
> > >
> > > use DateTime;
> > > my $d = DateTime->new(...);
> > > my $today = $d->today;
> > >
> > Hmm, I'm not too big on constructors being called on an object, as opposed
> > to a class. You'd expect different behavior at least.
I'm not exactly sure how it should be documented but I took a stab at it anyways.
-J
--
--- DateTime.pm 2003-08-02 22:51:07.0 -1000
+++ doc.DateTime.pm 2003-08-03 10:21:15.0 -1000
@@ -1614,6 +1614,13 @@
This class method is equivalent to calling C with the
value returned fro
> > What would DateTime::HiRes offer besides a hires_now() method?
>
> Nothing. :)
>
> DateTime::HiRes->now()
>
> reads nicely.
It also doesn't load Time::HiRes unless we're actually going to use it. Which is
probably most of the time. I guess we could get the same effect with require inside
o
> Mainly don't go with hires even though a 'famous' module already does.
Sounds reasonable to me. Here is a revised version of the patch. I made a basic
attempt at testing. The tests I think are questionable are already inside a skip
block. That way it won't break the CVS version and hopeful
> > The more I think about this the more I like it. We'll only have to
> > commit the fractional seconds fix to DateTime.pm. I'd suggest
> > DateTime::HiRes.pm to be included with the DT distribution. The down
> > side is this functionality wouldn't be available to decorators unless
> > DateTime
> > # Because epoch may come from Time::HiRes
> > my $fraction = $p{epoch} - int( $p{epoch} );
> > -$args{nanosecond} = $fraction * MAX_NANOSECONDS
> > +$args{nanosecond} = int( $fraction * MAX_NANOSECONDS )
> > if $fraction;
>
> What's this for? I think it was working a
> > I take it back. I thought we'd have now() and hires_now(). I think
> > having nanosecond at 0 makes sense to most people.
>
> We have an awful lot of constructors already. Maybe we should put this into another
> package?
The more I think about this the more I like it. We'll only have to c
> I take it back. I thought we'd have now() and hires_now(). I think
> having nanosecond at 0 makes sense to most people.
We have an awful lot of constructors already. Maybe we should put this into another
package?
-J
--
I'm not really awake yet. I meant to say:
I'm not sure exactly how to test this. Call now several times and make sure that one
of the results is non-zero for nanoseconds?
-J
--
> In general, I have no qualms about dependencies if they're on
> known-to-be-good modules _and_ they provide some useful functionality. In
> this case, it's even less of a concern since Time::HiRes is a core module.
We can't import Time::HiRes's time as there is already a DateTime::time()
Index
> OTOH, maybe I dont understand how your DateTime->hires( 1 ) call
> would work without adding HiRes as a dependency.
It does - but it could be more of a please use it if you've got it. Having an
explicit constructor for the hires behavior says that your guaranteed to get it (IMHO).
Maybe your
> $dt = DateTime->now_high_res();
> or
> $dt = DateTime->now( high_res=>1 );
Thats a possibility too. Although to me that syntax would seem to guarantee HiRes
support to be available. I don't know if we want add Time::HiRes as a dependency.
-J
--
> Alternatively you could just test for it in places where it would be
> useful (which are ...?):
>
> if ($INC{'Time/HiRes.pm'}) {
> # Work in HiRes
> }
The only place it matters inside DT (from_epoch) already supports it.
> This means that if the user has loaded Time::HiRes, then we can us
Since from_epoch() already supports Time::HiRes I was thinking that a class method to
set use of this would be handy.
Something like:
DateTime->hires( 1 );
???
-J
--
Released to CPAN.
Available immediately from:
http://kolea.ifa.hawaii.edu/~jhoblitt/pm/DateTime-Format-Bork-0.02.tar.gz
Changes since 0.01
- bork() now clones passed objects
thanks to Eugene van der Pijll for the bug report
-J
--
> [1] Why UTC? Wouldn't Europe/Stockholm be more appropriate?
I committed this change to CVS but I think it may have uncovered some sort of weird
bug in DT::TZ. Could you run the tests from the CVS version and let me know if they
hang?
-J
--
> 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 :(
It's in RedHat's installer as well.
-J
--
> Perhaps it is useful to specify a rule that DT::Format formatting
> routines should never change the object they are passed. Before changing
> anything, clone the object first. Is this something to add to the
> development standards?
Thats a _very_ good idea.
> [1] Why UTC? Wouldn't Europe/Stoc
s a hash representing an alias and the locale it should map too.
=head1 CREDITS
Everyone at the DateTime C.
=head1 SUPPORT
Support for this module is provided via the [EMAIL PROTECTED] email
list. See http://lists.perl.org/ for more details.
=head1 AUTHOR
Joshua Hoblitt <[EMAIL PROTECTED]&g
> No, Dynloader's doing what it's supposed to, which is try to find an .so
> for the module. The problem is that the one it finds is for the wrong
> version.
No versioning information is written into the .so?
-J
--
> > > > bash-2.03# perl Makefile.PL --pm
> > >
> > > Why'd you do that? You told it to _not_ compile the XS version.
> >
> > Because thats where the problem is occurring.
>
> But why would people do that on Solaris is my question.
For some reason it doesn't always identify that gcc is available (
> > > - 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 blib directory.
> >
> > bash-2.03# p
> - 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 blib directory.
bash-2.03# perl Makefile.PL --pm
Ch
> 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
Just to be clear - I intended this to be humorous. I was not truly equating that
'stuff' to one true DateTime {TM}. :)
Cheers,
-J
--
On Tue, 29 Jul 2003, Joshua Hoblitt wrote:
> > Date/Time type announcement
> > http://www.python.org/doc/2.3/whatsnew/node18.html#SECTION
> They suck, we rule.
I forgot the 'for entertainment purposes only' disclaimer. :)
-J
--
> Date/Time type announcement
> http://www.python.org/doc/2.3/whatsnew/node18.html#SECTION000181
>
> 'DateTime' Object
> http://www.python.org/doc/2.3/lib/module-datetime.html
>
> Gregorian Calendar from Calendrical Calculations that requires 'DateTime'
> http://www.python.org/doc/2
Date/Time type announcement
http://www.python.org/doc/2.3/whatsnew/node18.html#SECTION000181
'DateTime' Object
http://www.python.org/doc/2.3/lib/module-datetime.html
Gregorian Calendar from Calendrical Calculations that requires 'DateTime'
http://www.python.org/doc/2.3/lib/module-
Released to CPAN.
Available immediately from:
http://kolea.ifa.hawaii.edu/~jhoblitt/pm/DateTime-Calendar-Mayan-0.06.tar.gz
Changes since 0.05
- add nanosecond preservation
- fix undef being returned from utc_rd_values for rd_secs when not preserving from
an object
-J
--
On Tue, 29 Jul 2003, Dave Rolsky wrote:
> 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.
Minutes? :)
-J
--
> I've gotten this as a test failure from one of the automated CPAN tester
> boxes, also running Solaris. It could just be an @INC problem, in that
> it's finding the wrong .so file first.
It shouldn't be loading a .so file at all. Isn't DynaLoader aware of versioning?
-J
--
Hi Tim,
Continuing in my role as the unofficial DT QA department I've being trying to break
things. I've had some success in this endeavor on a system with DT 0.13/XS installed
attempting to upgrade to 0.1402/pureperl.
I think that XSLoader isn't correctly handling the version argument - it's
> I have released the 0.04 version of DT::C::FrenchRevolutionary
> - The bug has been fixed
All the tests pass for me on Linux and Solaris now.
Thanks,
-J
--
Hi Rick,
Here is a simple patch that:
uses DT::Locale instead of DT::Language
maintains full backwards compatibility (well at least all the existing tests pass)
adds support for a 'locale' in the constructor
adds a locale method (alias for the language method)
adds tests for a pattern specified w
> Don't know. This isn't an application using DateTime, and the problem
> has just been reported to me. Plus I don't have Debian. Mark or Scott
> can you answer this question.
You mentioned that. I'd like to know if DT is experiencing the same issue.
> > I've never used a true "Olson" name in th
Hi Dave,
Passing bad parameters to either now() or today() causes errors to be returned with
from_epoch apearing as the callee.
"DateTime::from_epoch but was not listed in the validation options: ..."
I think this is a bit confusion during debugging and all the other constructors
(except clone
> > > Should we guarantee (well specify anyways) that value passed/returned for
> > > rd_nanosecs is < 1 second?
> >
> > Yes.
>
> I just checked in the 1st draft of changes to datetime-calendar.pod. I'll add this
> too.
Ok - just checked that in. Comments?
-J
--
> > Should we guarantee (well specify anyways) that value passed/returned for
> > rd_nanosecs is < 1 second?
>
> Yes.
I just checked in the 1st draft of changes to datetime-calendar.pod. I'll add this
too.
-J
--
> 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 for rd_nanosecs
is < 1 second?
-J
--
>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.
-J
--
> I installed "DateTime", then installed "Bundle::DateTime". That worked.
> So I still don't understand what broke, but at least it sorta worked. :)
DT::F::Strptime has a dep on DT::Language which was part of DT but has been dropped in
favor of DT::Locale (although the language parameter is stil
> en_US is root... everything else inherits from that.
I understand now. en_US, en, and others are aliased to root inside LocaleCatalog.pm.
-J
--
On Sat, 26 Jul 2003, Joshua Hoblitt wrote:
> > There is no DateTime::Locale::en_US in the CPAN
> > version. Is this a bug or I'm using it the wrong way?
>
> It's a bug. Theres even a locale alias that tries to point at it.
>
> 'eng_US'
> There is no DateTime::Locale::en_US in the CPAN
> version. Is this a bug or I'm using it the wrong way?
It's a bug. Theres even a locale alias that tries to point at it.
'eng_US' => 'en_US',
en.pm seems to be missing as well as there's an alias for it as well.
'eng'
On Fri, 25 Jul 2003, Dave Rolsky wrote:
> 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
> 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
So that Redhat - What version of the dist? I'm on Gentoo 1.4rc2.
For me the parser makes it to:
af
af_ZA
(
> I think the tests in DateTime.pm/ that depend on DT::Locale should be
> moved to DT::Locale.
Can you try the CVS version now? Dave and I both just tried to commit the fix. :)
-J
--
> I think the tests in DateTime.pm/ that depend on DT::Locale should be
> moved to DT::Locale.
DT::TZ handles this by not running it's DT dependent tests if DT isn't available.
This is allows DT::TZ to be install automatically as a dependency of DT. DT::Locale
should be handled the same way.
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?
-J
--
> > But a more "intelligent", single implementation, is
> > easier to use.
>
> Not necessarily. We'll just need to do some clever dispatching based on the named
> parameters.
On second thought lets not.
-J
--
> That's more or less how it works, actually :)
I admit I've been way to busy to really follow how this module has been evolving (or
even started!). It's unfortunate because I really am interested in it...
> > > week_year / set_week_year
> > > week_number / set_week_number
> > > day_of_we
> 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:
Is it possible express all of these as:
If year is known:
a DateTime + a DT::Duration
If year is not known:
a null +
SF imported my CVS tree for DT::TZ::Alias this morning.
-J
--
For those of you that don't track DT CVS commits I added ./docs/datetime-namespace.pod
to the website about a week ago along with some other minor changes to the developer
docs.
I'd already updated the pod version to reflect the changes coming in '0.14' but I
hadn't synced this with the html ve
> I hate to say this but the language stuff may be deprecated in favor
> of locales...
Maybe eq 'is' in what will soon be released as DateTime '0.14'.
> 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
>
> I wanted to use the timezone long names for users to indicate their current
> timezone/DST but many of the major cities are missing from the list. How
> does somebody from say, America/Dallas, indicate their timezone? I'm
> assuming that they would select the nearest city to their current locatio
> For the rest of the list: I have a question about the use and implementation
> of TimeZone names. Can I ask it here or is there another list where it would
> be more OT. Not sure if this list is just for the development of the
> package.
Have you looked at the FAQ? If so and it didn't answer yo
> ?? We can't know utc_rd_values for incomplete datetimes. What is the
> utc_rd_value of "July 22"?
I was referring to the base object.
> The current implementation is sort of half-a-decorator. I started
> reworking it to be a real decorator, and then got stuck on the "day 30 for
> February ba
> 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
> incomplete object only has a known year, there's no reason to error out
> I committed it this afternoon (just the Locale change not the Common
> parser).
I'll take a look at soon as I get a chance.
Thanks,
-J
--
> > 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
--
Can anyone with a Solaris system get this to fail? I've tried it on a number of
Solaris 8 systems (the same at the smoke test) and the local time detection code is
working. I'll add support for /etc/TIMEZONE anyways but I'm wondering if it's a
specific problem with the smoke-box.
-J
--
> ---
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.
-J
--
-- Forwarded message --
Date: 21 Jul 2003 11:37
Released to CPAN.
Available immediately from:
http://kolea.ifa.hawaii.edu/~jhoblitt/pm/DateTime-TimeZone-Alias-0.05.tar.gz
Changes since 0.04
- floating, local, UTC, Z, and offsets can now be aliased
- docs updated
Cheers,
-J
--
> But there's a conflict between several expanded formats:
> ±_C_CCYYMMDD (>= 9 digits)
> ±_C_CCYYDDD (>=8 digits)
> ±_C_CCYY (>= 5 digits)
> ±_C_CC(>= 3 digits)
> unless you specify the number of digits used for the year/century.
The judgment call I've made for DT::F::ISO8
Did anyone contact the author (Blair Zajac) about renaming this module?
-J
--
101 - 200 of 394 matches
Mail list logo
