Queue: DateTime-Format-ISO8601
Ticket URL: http://rt.cpan.org/Ticket/Display.html?id=23307
Joshua Hoblitt via RT wrote:
URL: http://rt.cpan.org/Ticket/Display.html?id=23307
I haven't given RFC 3339 an in depth study but it appears to be a
significant simplification of ISO 8601
I haven't given RFC 3339 an in depth study but it appears to be a
significant simplification of ISO 8601:2000. As you note, it's not
really just a subset either as not all valid RFC 3339 formats are valid
ISO 8601 formats because of the time date separator relaxation. It's
also not clear to me
On Sat, May 05, 2007 at 08:57:16PM -0700, Jonathan Leffler wrote:
I can't answer for the developers of DateTime::Format::ISO8601, but it is
not clear that they are required to support the notation, though I suspect
it would not be hard to do so, possibly by some specialized sub-class
0.05 was supposed to be a very minor change over the previous release,
only disabling a single failing test. Instead, 0.05 ended up being
based off my CVS head which hadn't had any of the changes on my 0.04
fixes branch merged into it. In short, 0.05 is borked and is full of
serious regressions.
Thoughts or comments on this bug that was just filed on DT::F::ISO8601
would be appreciated. The summary: -MM-DD HH:MM:SS is not accept
by DT::F::ISO8601 and I don't believe it's a valid 8601 format.
http://rt.cpan.org//Ticket/Display.html?id=23307
-J
--
pgpzupHphCe99.pgp
On Thu, Oct 05, 2006 at 11:06:20AM +0100, David Cantrell wrote:
Bill Moseley wrote:
BTW:
'print UnixDate(Dec 3, 2006 9am PST, %Z %Y %m %d %H %M %S %z )'
PDT 2006 12 03 10 00 00 -0700
I believe that code like that should fail - or at least spit a warning -
as PST is
Eh, looks like SF's svn repo is down.
-J
--
On Sat, Sep 09, 2006 at 09:12:56AM -1000, Joshua Hoblitt wrote:
I can confirm that a large number of tests are failing for me as well.
Something has clearly change behavior. Probably a local timezone issue.
Are you 5 hours off UTC?
-J
Is all that stuff just a reinvention of the wheel? What's the value add
over DateTime and the zillions of other date/time modules already on CPAN?
I have to admit I haven't really looked at your code in depth but I
don't see how you can accurately be calculating TT/etc. without doing an
Oops - I made a typo. Replace TT with UT1. (TT is trivial to calculate).
-J
--
On Sun, Jul 16, 2006 at 10:25:51PM -1000, Joshua Hoblitt wrote:
Is all that stuff just a reinvention of the wheel? What's the value add
over DateTime and the zillions of other date/time modules already on CPAN
On Mon, Jul 17, 2006 at 05:42:29PM +0100, Zefram wrote:
There's leap seconds, but I presume that's intentional. AFAIK DateTime
operates correctly within its designed limits.
Entirely accidental, I assure you! They are part of UTC. Which in all
likely hood is what your system clock is synced
On Mon, Jul 17, 2006 at 10:35:39PM +0100, Zefram wrote:
Eugene van der Pijll wrote:
For every future leap second, there will be a version of DT that
handles it correctly. That the current implementation can not, is only
an implentation problem :-).
Having the implementation thus permanently
- Forwarded message from Jay Buffington [EMAIL PROTECTED] -
From: Jay Buffington [EMAIL PROTECTED]
Date: Tue, 20 Dec 2005 21:27:31 -0800
To: Perl Best Practices [EMAIL PROTECTED]
Subject: [PBP-pm] Working with dates
Hi Everyone.
I'd like some feedback on best practices for working with
Any ideas as to what's going on with parsing Pod on win32?
Thanks,
-J
--
- Forwarded message from Jim Lancaster [EMAIL PROTECTED] -
From: Jim Lancaster [EMAIL PROTECTED]
Date: Fri, 28 Oct 2005 21:01:58 -0500
To: [EMAIL PROTECTED]
Subject: Unable to install DateTime::Format::DateParse
You've got the wrong suspects. RT::Date is part of the RT product.
http://www.bestpractical.com/rt/
There are instructions on where to send a bug report here:
http://rt3.fsck.com//NoAuth/Buglist.html
Cheers,
-J
--
On Wed, Oct 19, 2005 at 12:24:53AM -0700, wk.Fung wrote:
Hi,
On Tue, Sep 06, 2005 at 09:57:11AM -0500, Dave Rolsky wrote:
On Mon, 5 Sep 2005, Joshua Hoblitt wrote:
If I understand you correctly, your position is that user's will be
confused by DST transitions screwing up additions but won't notice the
same effect on subtractions?
No, they'll notice
On Mon, Sep 05, 2005 at 03:15:35PM -0500, Dave Rolsky wrote:
This means that if you do subtract_datetime on two objects you end up with
this situation:
$dur = $dt2 - $dt1
$dt1 + $dur != $dt2
$dt2 - $dur != $dt1
But honestly I don't really think that's a bug, and it's covered in
On Mon, Sep 05, 2005 at 11:49:33PM -0500, Dave Rolsky wrote:
my $dt = DateTime-new( year = 2003, month = 9, time_zone =
'America/Chicago' );
$dt-add( months = 3 );
Now what do you expect that to produce? I suspect 99% of users expect
that to produce 2003-12-01T00:00:00. In other
On Mon, Aug 08, 2005 at 10:45:19AM -0500, Dave Rolsky wrote:
On Mon, 8 Aug 2005, John Siracusa wrote:
On 8/8/05, Dave Rolsky [EMAIL PROTECTED] wrote:
Does anyone object to adding Math::BigFloat as a
prereq?
What are the performance/memory implications? I don't object to the
prereq,
On Mon, Aug 08, 2005 at 09:02:06AM -1000, Joshua Hoblitt wrote:
On Mon, Aug 08, 2005 at 10:45:19AM -0500, Dave Rolsky wrote:
On Mon, 8 Aug 2005, John Siracusa wrote:
On 8/8/05, Dave Rolsky [EMAIL PROTECTED] wrote:
Does anyone object to adding Math::BigFloat as a
prereq?
What
Since nobody has commented on this patch does that mean everybody agrees
that it's a good idea? :)
-J
--
On Mon, Jul 25, 2005 at 04:10:53PM -1000, Joshua Hoblitt wrote:
Hi Folks,
I stumbled across a limited precision issue while working on
DateTime::Format::DateParse.
One of 'epoch' test
The 'Al might be a whiner' release.
Released to CPAN.
Changes since 0.0402
- update doc format
- tidy Build.PL
- auto-generate Makefile.PL
- change set_base_datetime() to use DT's overloaded = instead of
-compare()
- tidy test sources and reduce runtime
Cheers,
-J
)-as_int-bstr;
}
--
-J
--
On Mon, Jul 25, 2005 at 04:10:53PM -1000, Joshua Hoblitt wrote:
Hi Folks,
I stumbled across a limited precision issue while working on
DateTime::Format::DateParse.
One of 'epoch' test values used in Date::Parse is 1045469647.198189,
which is just beyond the precision
Hi Folks,
I stumbled across a limited precision issue while working on
DateTime::Format::DateParse.
One of 'epoch' test values used in Date::Parse is 1045469647.198189,
which is just beyond the precision of an IEEE 754 64bit value (a C
double). So internally (on all IEEE 754 compliant
On Sun, Jul 24, 2005 at 02:30:54PM +0900, Daisuke Maki wrote:
- Is there any reason why the locales are not singletons?
None that I can think of.
- Can I make them singleton?
Locale objects are cached during 'load' so that the same object may be
shared between multiple DTs. This cache
/ for more details.
AUTHOR
Joshua Hoblitt (JHOBLITT) [EMAIL PROTECTED]
COPYRIGHT
Copyright (c) 2005 Joshua Hoblitt. All rights reserved. This program
is free software; you can redistribute it and/or modify it under the
same terms as Perl itself.
The full text
On Fri, Jul 22, 2005 at 10:46:24PM -0300, Flavio S. Glock wrote:
Dave has started DateTime, and I'm working on Pugs modules
DateTime::Span, DateTime::SpanSet and a new module called
DateTime::Recurrence, as well as the base modules Span, Recurrence,
and Set-Infinite. Everything is under the
On Thu, Jul 21, 2005 at 01:54:30PM +1000, Rick Measham wrote:
I want to wrap this up and release so there's 24 hours to finalise the
name. Here's the names I like thus far:
DateTime::LazyInit (from John Siracusa)
DateTime::Mock (from Joshua Hoblitt)
DateTime::Diet (original
Hi Folks,
It appears as if Pugs is very close to being able to host a major
framework like DateTime. I think that it's 'time' to start considering
porting DateTime to Perl6. Even if for no other reason then to help
debug Pugs. The big question that I believe needs to be settled is do
we make a
On Fri, Jul 08, 2005 at 03:34:22PM -0500, Dave Rolsky wrote:
On Fri, 8 Jul 2005, Rick Measham wrote:
It's been discussed before, and the main reason is below. There's just no
way to properly parse a datetime. You can make 'best guesses'. But you
should probably use something else to make
On Tue, Jul 19, 2005 at 10:44:17AM -0500, Anthony, Joseph wrote:
The string date has a value as 'Jul 18, 2005 7:45:17 PM' and when I directly
store it to an oracle database field datetime, it's storing as
07/18/2005 07:45:17 AM. Not sure why it's converted to AM instead PM.
The issue is either
On Wed, Apr 27, 2005 at 10:39:08AM -0500, Dave Rolsky wrote:
On a side note, I don't really like the namespace Sort::Key itself, since
it's not clear what that means. I'd think something like Sort::Datatype
or Sort::Custom or something like that might be a little clearer. This is
On Tue, 21 Dec 2004, Dave Rolsky wrote:
3.) Doesn't your innovation mean that, for some folks, the date changes
when the sun is overhead?
Yes ... but those folks live in the middle of the Pacific Ocean.
They don't care what day it is anyway!
Some (but not all) of us do care what day it is... :)
-J
Hi Tim,
It looks like the normalization is hosed.
Cut 'n Paste-able example:
--
use DateTime::Duration;
my $dur = DateTime::Duration-new( hours = 2.67 );
print hours: ,$dur-in_units( 'hours' ), \n;
print minutes: , $dur-in_units( 'minutes' ), \n;
print seconds: , $dur-in_units(
On Mon, 13 Dec 2004, Dave Rolsky wrote:
On Mon, 13 Dec 2004, Joshua Hoblitt wrote:
It looks like the normalization is hosed.
This method, for the nth time, does not convert between units which do not
have a fixed conversion rate.
Whooo, I seem to have missed the bus here. Wasn't the entire point
On Mon, 13 Dec 2004, Tim Jenness wrote:
On Mon, 13 Dec 2004, Dave Rolsky wrote:
Maybe it could be something like DT::Duration::Fractional? What do others
think?
A variant of Duration that assumes standard lengths for day, minutes, hour
etc, and with a caveat that it will always add seconds when
Were CVS tags intentionally omitted for the 0.22 and 0.23 releases of
DateTime.pm?
-J
--
Who is the point of contact for AS on this issue?
-J
--
On Tue, 2 Nov 2004, Dave Rolsky wrote:
On Mon, 1 Nov 2004, Yitzchak Scott-Thoennes wrote:
Not that I'm blaming DateTime; there's plenty of blame to go around.
ActiveState is to blame for (as rumor has it) having someone maybe
sometime
: Sun, 31 Oct 2004 08:43:14 -0500
From: Ricardo SIGNES [EMAIL PROTECTED]
To: Joshua Hoblitt [EMAIL PROTECTED]
Subject: Re: Time::Human
* Joshua Hoblitt [EMAIL PROTECTED] [2004-10-30T22:08:31]
I'd like to see Time::Human become just a wrapper for
DateTime::Format::Human.
Would it be possible for you
That is goofy... has anyone opened a trouble ticket on this or complained
directly?
-J
--
On Mon, 1 Nov 2004, Dave Rolsky wrote:
On Mon, 1 Nov 2004, Joshua Hoblitt wrote:
Has anyone that is a win32/activeperl user complained to Activestate that
they are not providing a DateTime PPM? I assume
Released to CPAN.
Changes since 0.0401
- add 8 missing formats, patch by Kelly McCauley
Cheers,
-J
--
Hi Matt,
On Tue, 19 Oct 2004, Matt Sisk wrote:
[EMAIL PROTECTED] wrote:
Hi Joshua,
I am not sure about this. I need to check with Paul to see if this is valid.
Valid? Other than the patch he submitted appeared to not take into
account a decimal place, there's nothing invalid
Released to CPAN.
This is a port of Time::Human to the DateTime::Format API.
Cheers,
-J
--
On Sat, 4 Sep 2004, Dave Rolsky wrote:
On Fri, 3 Sep 2004, Joshua Hoblitt wrote:
Except for all those non-inheritable lexical variables in the DateTime namespace...
Like what, the validation specs?
Ya. Those are the lexicals that completely wreck inheritance. Instead of
fixing
On Thu, 2 Sep 2004, Dave Rolsky wrote:
Well, the original question was in regards to subclasses of DateTime.pm.
Given that a subclass will inherit from_object(), that seems good enough.
my $my_dt = My::DT::Subclass-from_object( object = DateTime-new );
That should work without any
On Mon, 19 Jul 2004, Eugene van der Pijll wrote:
UTC was not defined before 1972-01-01. In DateTime, utc is used as time
zone before 1972. The behaviour of our utc before 1972 is undefined, and
it's perfectly possible to have a leap second 1971-12-31T23:59:60.
Except that UTC is *defined* as
Hi Folks,
I'm having an itch to convert UTC-TAI. I started off writing this a
DateTime::Format module because the conversion is so simple but since TAI isn't just a
display formating of the Gregorian/UTC system (different epoch, no leapseconds, etc.)
I'm now thinking this should be
Hi Folks,
DateTime::LeapSecond claims that there have been 23 leap-seconds since the start of
UTC. This is _incorrect_. There have been only 22 leap-seconds in the history of
UTC. This error is introduced on be the addition of a leap-second on 1972-01-01.
That is the date when the delta
Hi Dave,
Are you going to go ahead with the conversion? I'm eager to switch to SVK.
Cheers,
-J
--
On Wed, 21 Apr 2004, Dave Rolsky wrote:
I'm getting fed up with the damn sourceforge CVS instability and slowness.
What do people think of moving to Subversion, hosted either on my own box
On Wed, 21 Apr 2004, Dave Rolsky wrote:
I'm getting fed up with the damn sourceforge CVS instability and slowness.
But at least it's backed up occasionaly...
What do people think of moving to Subversion, hosted either on my own box
(svn.urth.org) or maybe svn.perl.org if I can talk Ask
It seems we've actually had a fair amount of coverage on Perlmonks.
http://www.perlmonks.org/index.pl?node=+DateTimego_button=Search
-J
--
On Sun, 4 Apr 2004, Dave Rolsky wrote:
On Sun, 28 Mar 2004, Rick Measham wrote:
I don't know who he is, but DateTime is the only module mentioned in
On Mon, 29 Mar 2004, Dave Rolsky wrote:
On Sun, 28 Mar 2004, Eugene van der Pijll wrote:
Is it possible to detect mixed durations other than checking all of
is_positive, is_zero and is_negative? For example by adding an is_mixed
method?
Something like that, with a better name than
Hi Graciliano,
On Sun, 21 Mar 2004, Graciliano M. P. wrote:
I have just released the module Date::Object, that in the first view is an
alternative to DateTime, at least for the most common things when handling
dates.
It nice to see that the DateTime project has become so well known. :)
Released to CPAN.
Available immediately from:
http://kolea.ifa.hawaii.edu/~jhoblitt/pm/DateTime-Calendar-Mayan-0.0601.tar.gz
0.0601 Wed Mar 17 21:56:08 HST 2004
- fix test failures
Cheers,
-J
--
Does it make sense to add Module::Build to the bundle? DateTime::Locale immediately
asks for it.
-J
--
There are two threads running on the p6i list right now dealing with date and time
handling. The threads are Dates and Times and Epoch Larry Wall has stated
that by default Perl 6 will return time as a floating point number of seconds since
2000. Regardless of what Perl 6 does, I'm
On Sat, 17 Jan 2004, David Wheeler wrote:
On Jan 16, 2004, at 7:55 PM, Joshua Hoblitt wrote:
I would do it the way we did it in DBD::Pg: Put it in t/lib:
Why not use Module::Install?
Because not everyone is connected to a network with access to a CPAN
mirror. And those people will hate
On Sun, 18 Jan 2004, Jonathan Leffler wrote:
When I try to build DateTime::Format::ISO8601 v0.04, I'm getting a
test failure in t/02_examples.t:
t/02_examples.NOK 24# Failed test (t/02_examples.t at line
156)
# got: '2004-04-11'
# expected: '2004-04-12'
On Fri, 16 Jan 2004, David Wheeler wrote:
I would do it the way we did it in DBD::Pg: Put it in t/lib:
Why not use Module::Install?
-J
--
On Mon, 8 Dec 2003, Mathieu Arnold wrote:
Shouldn't this be a DateTime::Calendar:: thing ?
http://datetime.perl.org/developer/namespace.html
-J
--
You would still have to create the timezone singletons -- unless you're
suggesting that these would be destroyed when not in use, you would
still end up running into the same memory issues once enough timezone
objects have been created.
And you wouldn't be able to take advantage of page
Is this ALL each timezone provides, and nothing else? Does anything directly
access timezone object structures in any other way? Because if not, it
should be pretty easy to create an XS wrapper to implement only these
functions, even say by accessing the POSIX zoneinfo database given a
Released to CPAN.
Available immediately from:
http://kolea.ifa.hawaii.edu/~jhoblitt/pm/DateTime-Format-ISO8601-0.04.tar.gz
Changes since 0.03
- require DT 0.18 and DT::F::B 0.77
- recommend Test::Pod 0.95 and File::Find::Rule 0.24
- doc update
- test update
- fix bug in -YY
I've been seeing this build error for a couple of months now on at least half a dozen
different systems.
-J
--
/usr/bin/perl Build test
t/00load...ok
t/01conversionsNOK 3# Failed test (t/01conversions.t at line 69)
# got: '2003032300:00:00'
# expected:
by this 'compare' class or be extended to include
comparison operators. Two DT::Q objects could be compared deterministically.
-J
--
From [EMAIL PROTECTED] Fri Nov 14 17:40:01 2003
Date: Sun, 17 Aug 2003 16:02:09 -1000 (HST)
From: Joshua Hoblitt [EMAIL PROTECTED]
To: DateTime [EMAIL PROTECTED
I don't think the memory usage of DT::TZ is really that excessive. It's been over 3
years since I've had a sever with less then 1GB of ram in it. That's easily enough
memory for 64 x 12.5MB apache children that aren't doing page sharing.
-J
--
Just out of curiousity...why the '_datetime' suffix on these methods?
Isn't that redundant? Or was it assuming that these methods might be
showing up in classes outside of the DateTime namespace?
To differentiate from: _date, _time, _span, etc.
And speaking of brevity...the 0.18 docs for
On Tue, 4 Nov 2003, Flavio S. Glock wrote:
Joshua Hoblitt wrote:
$span = $dti-span;
I really like the idea of being able to measure
the uncertainty in an object. What if the year
and day are known but not the month? Would a
span set be returned?
spanset would be a separate
$span = $dti-span;
I really like the idea of being able to measure the uncertainty in an object. What if
the year and day are known but not the month? Would a span set be returned?
-J
--
I've now re-organized the astronomical calculation portions of the
chinese calendar modules into the following. This should be nicer to the
namespace. Please let me know if they look ok:
http://www.wafu.ne.jp/~daisuke/DateTime-Util-Calc-0.01.tar.gz
On Tue, 21 Oct 2003, Daisuke Maki wrote:
1) the Astro stuff. Just where to put it??
So I know Joshua Hobblit has suggested
Astro::Calendrical::*
It kind of seemed like (because these functions are specifically to
calculate dates) it belongs more to DateTime::* namespace. Is there a
There's one problem with this modules. DT.pm relies on the time zone
object returning a value from the name() method, that when fead to
DT::TZ-new, will recreate the original object. This is used in DT.pm's
Storable hooks in order to avoid saving the whole time zone object. Right
now, if
Anyway, here's what I got so far with the Astro:: stuff:
Astro::Sun- stuff related to solar position
Astro::Moon - stuff related to lunar position
Astro::Common - common calculation utilities
How common is Common? Remember there is stuff like Astro::FITS::CFITSIO (also a
good
How about to refactor DateTime RD code into another
module? There is already enough use for rd, minutes
and seconds in other calendars to justify having a
base module.
I think we've been over this before haven't we? I thought the consensus was that a
base class would be a good idea but that
However, if DT::Duration is given 'year' units, it should not
automatically convert it to months, because I may want to use that
information in a non-gregorian context.
Well, you might, but you can't ;)
I agree completely.
Seriously, I think this idea that DateTime::Duration should work
First: How many of a particular DOW are in a
period. This is just a matter of dividing the
total days by seven then adding one if
needed. If a function were added for this,
then I imagine its more a part of
DateTime::Span rather than DateTime itself.
I already said this. :)
Secondly you
I'm not sure about the count in a year, but I frequently need to
determine how many of a given day of the week fall in a given month
of the year, or, more precisely, given that today is Saturday,
September 20, I need to figure out whether today is the first,
second, third, fourth, or fifth
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
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
--
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
--
The only problem is that DT::subtract_datetime doesn't use it. It
probably should. (It would be even better if there was an option to
calculate the difference in days secs. But the default should probably
be to return a difference of months, days, minutes, seconds.)
I think the default
There's no official limit on offsets are there? I can envision some
small country declaring an offset of greater then 24hours.
You can? That doesn't make much sense to me. If it happens, we can
change the code ;)
The universe doesn't always make sense to you? :) I choose 99:59:59 as
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',
Hi Mattew,
$birth=DateTime-new(year=1968,month=6,day=28);
print $birth-ymd.\n;
$today=DateTime-today;
print $today-ymd.\n;
$age=$today-$birth;
print $age-years.\n;
$age is a DateTime::Duration object. Unfortunately math with these object can be a
little non-intuitive.
I get this
Again I fail to see the logic or even value in the DateTime::Duration
behaving as above. But, I'm sure I'm probably just missing something
important.
Durations are independent of dates and times.
The only one that does makes since is Deltas but only
because it is returning a hash that has
Okay, so maybe a new constructor then? DateTime-localtime()? Getting
the current local time seems more common than, say, constructing a
DateTime object from a day of the year, IMO :)
We have enough constructors as it is. I could be talked into:
DateTime-now( time_zone = 'local' );
But
Maybe there should be an extra accessor -link_name. (They're called
links in the TimeZone innards). Then when -time_zone_short_name is
called and it has no value, it return -link_name. Same for long_name.
I don't like that at all. You really should be creating new classes with your
specified
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 issue of
What I want is the reverse of what alias does. Or rather I'd like
timezone to remember what value it was created with. If I create an
alias 'EST' = 'UTC' and then create a datetime with 'EST', I'd like to
get EST as the name rather than UTC.
Awww - I understand what your asking for now. We
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
So are we back to DT::HiRes? Or just rename the constructor? I would
like to see this functionality make it into the next release.
I guess sticking it in a separate module DateTime::HiRes works, since that
way we don't force people to load Time::HiRes if they don't need it.
What about
DateTime-now( time_zone = 'local' );
It already works this way.
See what happens when I read my email before morning coffee. :)
-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
--
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 the
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 would have
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 so
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
1 - 100 of 285 matches
Mail list logo
