Dear all,
I am quite thrilled to announce that after several months of hard work,
I have released the Perl module DateTime::Format::Intl[1]. It mirrors
its JavaScript equivalent of Intl.DateTimeFormat[2]. The algorithm is
quite elaborate, replicating how it works in web browsers. I also had
Hi Marcel,
Yes, that sounds like a bug. I've cc'd the current maintainer of that
module, Mike Wisener, but I'd also suggest reporting the bug via rt.cpan.org
at https://rt.cpan.org/Public/Dist/Display.html?Name=DateTime-Format-MySQL
Cheers,
Dave Rolsky
http://blog.urth.org
htt
The DateTime::Format::MySQL formats microseconds incorrectly in the method
format_time. It simply concatenates the number of microseconds after the
formatted hms, however this is incorrect when the number of microseconds is
less than 100,000.
If a date object returns 12,345 microseconds at 5
A few minutes ago, I have released to CPAN a new
version v0.04 of DateTime::Format::Roman.
There is no new functionality. The purpose of this release
was to remove the incompatibilities (syntax errors) of
version v0.03 of this module with recent versions of
Perl (5.20.0) and to improve the
On Wed, Nov 28, 2018 at 12:03 AM Jean Forget wrote:
> Now I talk to Dave R.
>
> Dave, I have just seen that you have co-maintainer status
> on DateTime::Format::Roman. So can you upgrade the module
> according to my GitHub repo:
> https://github.com/jforget/DateTime-Format-Roman
You wrote the module DateTime::Format::Roman in 2003 and 2004.
At this time, it was up to date and conform to the CPAN and Perl
rules. But since then, the world has moved, and so did Perl and
CPAN and the CPAN testers. And now, with recent versions of Perl,
DT::F::R does not even compile.
In
:
>
>
> http://search.cpan.org/CPAN/authors/id/D/DR/DROLSKY/
> DateTime-Format-Strptime-1.73.tar.gz
>
>
> Is responding with a 404 and causing cpanm to not find the package.
>
>
> Thank you
>
>
> Tim
>
--
Jonathan Leffler #include
Guardian of DBD::Informix - v2
Hello
Just wanted to let you know that the url:
http://search.cpan.org/CPAN/authors/id/D/DR/DROLSKY/DateTime-Format-Strptime-1.73.tar.gz
Is responding with a 404 and causing cpanm to not find the package.
Thank you
Tim
On Sat, 22 Oct 2016, Bill Moseley wrote:
Should or can the formatter have a Storable hook to remove the parser? Any
suggestions on an easy workaround?
It'd probably be relatively easy to add Storable hooks to the module. All
it needs to do is save the arguments passed to new() and then fre
Howdy!
I upgraded Storable on an old app and started to get this error from
Storable:
Can't store REGEXP items at ...
Turns out the ORM we have is setting a DateTime::Format::Strptime formatter
on the DateTime objects and the formatter has a regex for the parser.
This happens as the
Yesterday I have released DateTime::Format::Baby,
initially created by Rick Measham.
The new version fixes all current RT issues:
-- assignment to $[
-- =back missing in the POD
-- spelling mistakes.
A few improvements:
-- UTF-8
-- more precise documentation.
Juste one glitch: the metadata state
Greetings,
tl;dr - format_datetime returns 2015-06-30 23:59:60 while MySQL considers
:60 invalid for datetimes.
I've run into quite the thorny issue when it comes to requesting data from
a MySQL Database.
*Overly Simplified and Contrived Sample MySQL Request*
my $start_date = DateTime::F
I expect the following test script to print a timestamp with
millisecond precision, but it doesn't. I'm running DateTime
version 1.03 and DateTime::Format::Epoch version 0.13 on 32-bit
Windows Vista with Strawberry Perl version 5.16.2.
What's wrong?
#!perl
use v5.16;
On Thu, 25 Oct 2012, N Heinrichs wrote:
If the locale's definitions for the 'medium' formats are
wrong/outdated (see http://cldr.unicode.org/index/downloads) you could
propose an update to the locale class itself, but I am unsure of the
"official" way to do this.
Note that DateTime::Locale is
Short answer: As of DateTime v0.72 on my local machine, %c is not
directly configurable.
A little more info:
%c is hardcoded to use the locale's `datetime_format_default` (search
for "strftime_patterns" in DateTime.pm)
DateTime::Locale::ko does not override 'datetime_format_default'. Nor
does it
We have been using formats %c, %x and %X for localizing dates based on
Locale. Mostly works ok, but for Korean we are getting this:
2012. 10. 18. 오후 4:09:05
where (I've been told) we would like this format:
2012년 10월 22일 월요일 오후 01:44 PDT
Is this formatting done in DateTime? I'm wondering
On 03/15/2012 08:58 PM, Nathan Gray wrote:
On Thu, Mar 15, 2012 at 04:43:32PM -0500, David McMath wrote:
A while back, I needed to some routines to parse timestamps so I
started using DateTime::Format::Strptime. The times were uniformly
formatted like "2012-03-13T07:43:07-07:00". Th
On Thu, Mar 15, 2012 at 04:43:32PM -0500, David McMath wrote:
> A while back, I needed to some routines to parse timestamps so I
> started using DateTime::Format::Strptime. The times were uniformly
> formatted like "2012-03-13T07:43:07-07:00". That /almost/ matched
> the p
Dear List,
A while back, I needed to some routines to parse timestamps so I started
using DateTime::Format::Strptime. The times were uniformly formatted
like "2012-03-13T07:43:07-07:00". That /almost/ matched the pattern
"%FT%T%z" but I couldn't figure out how
sult, or more
accurately *will* skew it honestly)
another duration object is created by subtracting a timezone
aware "now" from my timezone aware target, at which point i
attempt to use a DateTime::Format::Duration to display the
result, which for reasons i cannot imagine is coming out as
no
On Tue, Oct 11, 2011 at 09:33:32PM -0400, Nathan Gray wrote:
> Fixed in Convert::NLS_DATE_FORMAT 0.03.
> Dependency updated in DateTime::Format::Oracle 0.06.
On Wed, Oct 12, 2011 at 03:30:09AM +0200, PAUSE wrote:
> The uploaded file
>
> Convert-NLS_DATE_FORMAT-0.03.tar.gz
&
On Wed, Oct 12, 2011 at 12:00:14AM +0100, Zefram wrote:
> Jon Bjornstad wrote:
> >Am I missing something?
>
> Not really. It's an undocumented limitation of Convert::NLS_DATE_FORMAT,
> which is used internally by DateTime::Format::Oracle.
Fixed in Convert::NLS_DATE_
Jon Bjornstad wrote:
>Am I missing something?
Not really. It's an undocumented limitation of Convert::NLS_DATE_FORMAT,
which is used internally by DateTime::Format::Oracle.
-zefram
use DateTime::Format::Oracle;
$ENV{NLS_TIMESTAMP_FORMAT} = 'DD-MON-RR HH.MI.SSXFF AM';
$s = '15-FEB-03 02.39.06.167901 PM';
$dt = DateTime::Format::Oracle->parse_timestamp($s);
print $dt->nanosecond, "\n";
The above prints 167901000.
Trying to get a full
Andrew O'Brien wrote:
>Worth a doc patch or is it just me that finds this slightly confusing?
Definitely worth a doc patch. Well volunteered.
-zefram
Hi Zefram,
> From: Zefram [mailto:zef...@fysh.org]
>
> Andrew O'Brien wrote:
> >Can anyone explain why parse_duration() gives me 11 days, 8044 minutes
> plus change? (that's around 5.5 extra days) ?
>
> 8044 minutes is 134 hours plus 4 minutes. You also got 5 seconds
> instead
> of the expected
Andrew O'Brien wrote:
>Can anyone explain why parse_duration() gives me 11 days, 8044 minutes plus
>change? (that's around 5.5 extra days) ?
8044 minutes is 134 hours plus 4 minutes. You also got 5 seconds instead
of the expected 45. So altogether you got 11:0134:4:5 rather than the
expected 11
Hi all,
I'm puzzling over the following which may just be a misunderstanding of the
format string or something far more fundamental :-). I'm attempting to parse
datetimes of the following format:
hhmmss.n:000
For example, 11d 1h 34min 45sec 96000ns is 0011013445.960
Ron Savage wrote:
> I'm converting a home-grown module into a CPAN-ready one, which
> I'm planning to call DateTime::Format::Gedcom.
Shouldn't it properly be named DateTime::Format::GEDCOM?
> The spec for GEDCOM dates (of which there are several) is in
> http://wiki
Hi Folks
I'm converting a home-grown module into a CPAN-ready one, which I'm
planning to call DateTime::Format::Gedcom.
The spec for GEDCOM dates (of which there are several) is in
http://wiki.webtrees.net/File:Ged551-5.pdf
basically pages 45 to 48, with month and year stuff fu
Hi
I just got a patch for DateTime::Format::Pg this morning, and looks
like I have no
access to my old sourceforge account (they had a password reset
earlier this year,
apparently?), and I couldn't retrieve my account information via their password
reset thingie even after trying all
DateTime::Format::Natural parses currently input strings successfully
only if the entire string is a valid expression. It has been proposed
that DateTime::Format::Natural also should be able to extract expressions
from a string which has parts not belonging to an expression, like:
"se
Doh -- I'd forgotten this myself.
What's your PAUSE ID?
--d
2010/9/27 Gregory Williams :
> On Sep 26, 2010, at 3:47 PM, Dave Rolsky wrote:
>
>> Doh, apparently I only have comaint. Daisuke Maki has primary, it seems.
>>
>> Daisuke, can you give Gregory comaint?
>
> Do you want me to completely t
On Sun, 26 Sep 2010, Gregory Williams wrote:
Do you want me to completely take over ownership of the module or is
there a way I should be looking to work with the existing DateTime svn?
I'll leave that up to Daisuke. If he doesn't want it either, he can give
you primary.
As far as svn, if y
On Sep 26, 2010, at 3:47 PM, Dave Rolsky wrote:
> Doh, apparently I only have comaint. Daisuke Maki has primary, it seems.
>
> Daisuke, can you give Gregory comaint?
Do you want me to completely take over ownership of the module or is there a
way I should be looking to work with the existing Da
On Sun, 26 Sep 2010, Gregory Williams wrote:
I'd be happy to give it to you. I don't really use it much myself.
If you have abandoned the module, I'll maintain it. Transfer permissions
to me (GWILLIAMS) on pause, and I'll see about applying the patch and
releasing a new version.
Doh, appar
On Sep 24, 2010, at 9:15 PM, Dave Rolsky wrote:
> On Fri, 24 Sep 2010, Gregory Williams wrote:
>
>> I just posted a bug report to rt.cpan.org about a parsing problem with
>> DateTime::Format::W3CDTF. After posting the report, however, I noticed that
>> the same but
On Fri, 24 Sep 2010, Gregory Williams wrote:
I just posted a bug report to rt.cpan.org about a parsing problem with
DateTime::Format::W3CDTF. After posting the report, however, I noticed
that the same but was reported 5 years ago with a patch to fix the bug.
Is this module being maintained
I just posted a bug report to rt.cpan.org about a parsing problem with
DateTime::Format::W3CDTF. After posting the report, however, I noticed that the
same but was reported 5 years ago with a patch to fix the bug. Is this module
being maintained anymore? My code relies on this module, and it
On Thu, Sep 02, 2010 at 01:51:42PM -0500, Dave Rolsky wrote:
> Or you could do the simple version ...
> DateTime->now()->year();
Good call. Implemented.
> -dave
Matthew.
On Thu, 2 Sep 2010, Metz, Bobby wrote:
-Original Message-
From: Metz, Bobby
# Grab the year either via exec or via DateTime, your choice
chomp(my $year = `date '+%Y'`);
# --or--
my $year = strftime('%Y',localtime(time));
My apologies, I said "using DateTime" above but I used a POSIX e
> On Thu, Sep 02, 2010 at 01:24:03PM -0400, Metz, Bobby wrote:
> > You can add the current year to your string value prior to parsing.
>
> Thanks. I'll adopt the DateTime based version in your second mail.
You're welcome.
>
> > Of course you could also alter you syslog config to include the yea
rom: Matthew Hall [mailto:mh...@mhcomputing.net]
> > > Sent: Wednesday, September 01, 2010 8:33 PM
> > > To: datetime@perl.org
> > > Subject: DateTime::Format::Strptime bug report
> > >
> > > Hello all,
> > >
> > > I am trying to p
computing.net]
> > Sent: Wednesday, September 01, 2010 8:33 PM
> > To: datetime@perl.org
> > Subject: DateTime::Format::Strptime bug report
> >
> > Hello all,
> >
> > I am trying to parse BSD Syslog format time stamps, like this one:
> >
> > Sep
> -Original Message-
> From: Metz, Bobby
> # Grab the year either via exec or via DateTime, your choice
> chomp(my $year = `date '+%Y'`);
> # --or--
> my $year = strftime('%Y',localtime(time));
My apologies, I said "using DateTime" above but I used a POSIX example instead.
:D
DateTime c
rse the string value into a DT object
$val = $val . " " . $year;
my $parser = DateTime::Format::Strptime->new(pattern => '%b %d %H:%M:%S %Y');
my $dt = $parser->parse_datetime($val);
Of course you could also alter you syslog config to include the year, right?
&
Hello all,
I am trying to parse BSD Syslog format time stamps, like this one:
Sep 1 05:39:02
Using the DateTime::Format::Strptime class, the call is failing with
the following result, when I use the format string '%b %d %H:%M:%S'.
There is no use providing a month name (Sep) without
Hello,
I think that the parse functions of DateTime::Format::Duration do not
parse the nanoseconds correctly.
Here an example:
---
use strict;
use warnings;
use DateTime::Duration;
use DateTime::Format::Duration;
my $f = DateTime::Format::Duration->new(pattern =>
I'm going to take co-maint, at least for the next release. Primarily, I'm
interested in removing the dependency on deprecated DateTime::Locale
features. This will probably just involve moving some of that code
directly into DateTime::Format::Strptime itself.
After that, I'm open
Dave Rolsky wrote:
I've written email to modu...@perl.org with the intention of taking
this module over. I need to make it not rely on deprecated
DateTime::Locale APIs so I can finally release a new version of
DateTime::Locale.
If _someone_ else out there is dying to maintain this module, ple
That came off wrong.
I still think the best thing to do, rather than maintain a perl's
reimplementation of strptime is to move dt:strptime into
dt:strptime:pp and make dt:strptime a factory for dt:strptime:pp and a
new :xs version that uses a POSIX binding through POSIX::strptime.
Something kind o
I still think the best thing to do, rather than maintain a perl's
reimplimentation of strptime is to fork strptime into dt:strptime:xs
move dt:strptime to dt:strptime:pp and suggest the POSIX binding
version. Something kind of like the text:csv setup.
--
Evan Carroll
System Lord of the Internet
Rick, are you out there?
I've written email to modu...@perl.org with the intention of taking this
module over. I need to make it not rely on deprecated DateTime::Locale
APIs so I can finally release a new version of DateTime::Locale.
If _someone_ else out there is dying to maintain this modul
2009/12/14 Kevin McGrath
> The time_zone function in DateTime::Format::Strptime is only called with
> parse_datetime. I think a nice feature would be to also set the time_zone
> when calling format_datetime.
>
Keep in mind that DateTime::Format is a framework, and consistency w
There is nothing I want to do with parse_datetime. parse_datetime works
great and nothing I have said suggests that anything different should happen
when parsing a string to a datetime object. Everything about
parse_datetime, reading of a string and setting of a time_zone works exactly
how anyone
> Just the format_datetime function when it comes to the value which is
> assigned to the time_zone attribue. It's already an attribute of the
> module.
I simply /do not/ believe you understand the difference between being
1:30 "read-in the context of" America/Chicago, and "converting it with
dat
On Tue, Dec 15, 2009 at 11:39 PM, Evan Carroll wrote:
> How much would you want to be overridable, and set in the constructor
> of the DateTime::Format module?
Just the format_datetime function when it comes to the value which is
assigned to the time_zone attribue. It's already a
( $str, { time_zone => $tz1 } );
> $Strp->format_datetime( $str, { time_zone => $tz2 } );
>
> would be so evil. I want to get a formatted string based on pattern I
> provided as it would be displayed in the specified time_zone.
How much would you want to be overridable, and se
on layer: DateTime::Express
> (or DateTime::Represent)? It would subclass DateTime::TimeZone,
> DateTime::Locale, DateTime::Format and possibly others.
> --
> Jim Monty
>
>
my $string1 = $dt->strftime('%m/%d/%Y %T %Z');
my $string2 = $dt->strftime('%m/%d/%Y %T %z');
print "1: $string1\n";
print "2: $string2\n";
my $Strp1 = new DateTime::Format::Strptime(
pattern => '%m/%d/%Y %T %Z',
);
my $Strp11
te 'time_zone' seems pretty generic to me, it's not
> 'parse_time_zone' or 'time_zone_from_string'. The confusing part is that
> it's just named 'time_zone'.
I'm not arguing that it is the best name in the world, I'm just saying
it i
it then just always return a datetime in floating context?
In your later example where you 'go on with life', you should:
my $dt = $Strp->parse_datetime($my_string); #Floating
$dt->set_timezone($my_time_zone);
That way you only ever have one Format object. Why would you create a
Da
How about an entirely new, high-level abstraction layer: DateTime::Express (or
DateTime::Represent)? It would subclass DateTime::TimeZone, DateTime::Locale,
DateTime::Format and possibly others.
--
Jim Monty
->clone->set_time_zone($self->time_zone);".
The other problem is that you were suggesting overriding TimeZone to
make it confusingly apply to output patterns in the same explicit way
that it is currently applied to input patterns. Lets look at your
provided code:
my $Strp = new DateTime
I guess I'm just not very good at explaining the feature. If I have a
formatter that is related to a time_zone then I feel that input and output
of that formatter should be able to be based on that time zone.
my $Strp = new DateTime::Format::Strptime(
pattern => '%T',
> Basically I have a subclass of DateTime::Format::Strptime that takes one
> more parameter; a boolean that if true will format the datetime object with
> what is returned from time_zone.
This sounds like a bad idea, because you made note that you're doing
this on format_datetime
Re: time_zone and DateTime::Format::Strptime
>
> I know traditional convention does not account for this. That is why I
> was
> merely suggesting a 'format_with_time_zone' option you could pass to the
> new
> constructor.
>
> DateTime::Format::Strptime already takes
I know traditional convention does not account for this. That is why I was
merely suggesting a 'format_with_time_zone' option you could pass to the new
constructor.
DateTime::Format::Strptime already takes time_zone as a parameter. Why
should you have the set the time zone as an
ultiple
> users in the pattern and time_zone they prefer.
It is an interesting idea, but the traditional DateTime::Format
convention for format_datetime does not include timezone math already
done through $dt->set_time_zone( $tz ). If you had a variable output
pattern dependent on the timezon
That is an option, just thought that since DateTime::Format::Strptime
already provides a function for time_zone it would make sense for all things
parsed or formatted be done in respect to that time_zone.
Like I said I already have a class that takes care of this, my own subclass
of DateTime
On Tue, Dec 15, 2009 at 5:28 AM, Kevin McGrath wrote:
>
> Doing the work in parse_datetime does not work for me. In fact I almost
> never call parse_datetime directly and when I do it's to get the datetime
> passed in from a form into UTC. I need/want the time_zone conversion to
> also happen w
y $dt = $my_rose_object->transaction_date; # UTC Time
## Do work more queries, etc. all with UTC
In Template using the Strptime Plugin:
[% USE f = DateTime::Format('My::DateTime::Format::Strptime', { pattern =>
"%m/%d/%Y %T %Z", format_with_time_zone=>1, time_zone => user.
## Call-only pattern won't be cached
$dtf->parse_datetime( "time", { pattern => $pattern } );
$dtf->format_datetime( $dt, $pattern );
Just override the environmnent in the anon hash that is the second
argument to ->parse_datetime, all DateTimeX::Format modules
The time_zone function in DateTime::Format::Strptime is only called with
parse_datetime. I think a nice feature would be to also set the time_zone
when calling format_datetime.
I have my own subclass which does this now, but find myself using this more
and more in a lot of different projects. I
On Tue, Dec 01, 2009 at 07:48:35PM +0100, Roman Daniel wrote:
> Thank you very much for your investigation.
>
> As I recently found the UTC x floating time zone was caused by old
> DateTime::Format::Strptime (1.0601 vs 1.0702).
> It is pretty explicit in code.
>
> The u
Thank you very much for your investigation.
As I recently found the UTC x floating time zone was caused by old
DateTime::Format::Strptime (1.0601 vs 1.0702).
It is pretty explicit in code.
The upgrade will do for me.
Roman Daniel
2009/12/1 Nathan Gray
> On Mon, Nov 30, 2009 at 08:24:1
On Mon, Nov 30, 2009 at 07:24:38PM +, Zefram wrote:
> Nathan Gray wrote:
> >I have often thought it would be nice to be able to specify a
> >default time zone for DateTime, to use instead of floating.
>
> -1. Action at a distance.
Ah, yes. So maybe not such a good idea.
-kolibrie
signat
On Mon, Nov 30, 2009 at 08:24:10PM +0100, Roman Daniel wrote:
> No, DateTime objects returned don't have floating time zone (which would be
> more OK), but UTC.
>
> [dani...@irsay danielr]$ cat /tmp/try_tz.pl
> #use lib qw(/tmp/);
> use strict;
> use DateTime::Format::O
Nathan Gray wrote:
>I have often thought it would be nice to be able to specify a
>default time zone for DateTime, to use instead of floating.
-1. Action at a distance.
-zefram
No, DateTime objects returned don't have floating time zone (which would be
more OK), but UTC.
[dani...@irsay danielr]$ cat /tmp/try_tz.pl
#use lib qw(/tmp/);
use strict;
use DateTime::Format::Oracle;
my $dt = DateTime::Format::Oracle->parse_datetime('2009-11-03 12:23:33');
w
On Mon, Nov 30, 2009 at 11:55:46AM +0100, Roman Daniel wrote:
> All dates parsed by DateTime::Format::Oracle have their time zone invariably
> set to UTC.
The DateTime objects returned have a 'floating' time zone, since
DateTime::Format::Oracle does not do any time zone setti
All dates parsed by DateTime::Format::Oracle have their time zone invariably
set to UTC.
Is there any special reason for it?
I found it pretty annoying since I am used to store dates in db in local
(CET) timezone.
Could not it be possible to introduce some package configuration option and
place
I'll take it.
(and I won't make it Moose, as I believe there are people who do not
want Moose in their dependency chain)
--d
2009/11/2 Dave Rolsky :
> If someone else wants to maintain this module please let me know. I don't
> want it ;)
>
>
> 0.05 2009-11-01
>
> - Fixed a long-standing bug wher
On Sun, Nov 1, 2009 at 4:05 PM, Dave Rolsky wrote:
> If someone else wants to maintain this module please let me know. I don't
> want it ;)
I would have an interest in maintaining it if I could adapt it to work
with DateTimeX::Format. It will be backwards compatible.
--
Evan Carroll
System Lord
If someone else wants to maintain this module please let me know. I don't
want it ;)
0.05 2009-11-01
- Fixed a long-standing bug where a time zone other than UTC that had an
offset of 0 caused the format_datetime method to return the string "0". RT
#22802.
-dave
/*
On Thu, 29 Oct 2009, Pete Hodgson wrote:
Ever since British Summer Time ended in the UK last week my application
has been seeing a very interesting bug. Here's an isolated perl script
which demonstrates the issue:
This is a known bug - see
http://rt.cpan.org/Public/Bug/Display.html?id=22802
Hi Folks,
Ever since British Summer Time ended in the UK last week my application
has been seeing a very interesting bug. Here's an isolated perl script
which demonstrates the issue:
#!/usr/bin/perl
use strict; use warnings;
use DateTime::Format::W3CDTF;
use Dat
Hello,
I am using DateTime::Format::ISO8601-0.06 (perl, v5.10.0 built for
i686-linux-thread-multi-64int-ld).
When I try to parse '2009-W01-1', I get an following error: The
"'day_of_year' parameter ("-2") to DateTime::from_day_of_year did not
pass the 'is
going away, I guess I can put the conversion into
Strptime. It just seems to make more sense to have it live near data.
Once you remove it, if you want the str[fp]time pattern for a locale,
you'll have to use DT:F:Strptime.
(Maybe you could move it into DateTime::Format::Locale to turn th
Dave Rolsky wrote:
As far the locale data, that target will never stop moving. I'll keep
releasing new versions as the CLDR folks update their data.
and I, for one, thank you for it. Tea is on me the next time we manage
to be in the same space at the same time.
--
Shane P. McCarron
On Tue, 14 Jul 2009, Rick Measham wrote:
This release depends on DateTime::Locale 0.43 and the locale tests expect the
data provided by that module. This isn't future-proof, but Dave says that the
methods that provide the %x, %X and %c patterns to strftime are deprecated.
Once the target stops
On Tue, 14 Jul 2009, Rick Measham wrote:
Dave Rolsky wrote:
All those methods that convert to strftime patterns are deprecated and will
go away in a future release, so even if I fixed this bug, if you're relying
on them, your code will break eventually.
Erm .. I'm confused.
DateTime::Locale
PAN shortly, or you can download it
from Google Code:
http://datetime-format-strptime.googlecode.com/files/DateTime-Format-Strptime-1.1000.tgz
Cheers!
Rick Measham
--
Message protected for iSite by MailGuard: e-mail anti-virus, anti-spam and
content filtering.
http://www.mailguard.com.au
Dave Rolsky wrote:
All those methods that convert to strftime patterns are deprecated and
will go away in a future release, so even if I fixed this bug, if you're
relying on them, your code will break eventually.
Erm .. I'm confused.
DateTime::Locale will no longer provide the strftime patter
On Mon, 13 Jul 2009, Metz, Bobby wrote:
I'm sorry all to reply to my own post. I should have read the
original message first before replying to Dave's message. I see that
the module I'm questioning is at the root of the issue, so my apologies
again.
As someone who uses D
All,
I'm sorry all to reply to my own post. I should have read the original
message first before replying to Dave's message. I see that the module I'm
questioning is at the root of the issue, so my apologies again.
As someone who uses DateTime::Format::Strpt
Dave,
I'm not sure I understood your last post. Did you mean that those
strftime methods only found in DateTime::Locale::Base are going away? Or did
you mean that strftime methods in DateTime proper are being deprecated and
removed? If yes to the later, is DateTime::Format::Str
On Mon, 13 Jul 2009, Rick Measham wrote:
I believe there's an error in DateTime::Locale::Base that is screwing with my
fix. Line 277 turns the CLDR notation 'y' into the strftime notation '%y'.
From my reading of
http://www.unicode.org/reports/tr35/tr35-9.html#Date_Format_Patterns 'y'
should
L'équipe de serving.fr wrote:
We're having a problem installing DateTime::Format::Strptime (it seems
several people have alreayd posted on
http://www.nntp.perl.org/group/perl.datetime/ but we can't find the
solution)
As per the documentation, the correct place to repor
Hello David,
We're having a problem installing DateTime::Format::Strptime (it seems
several people have alreayd posted on http://www.nntp.perl.org/group/perl.datetime/
but we can't find the solution)
Here is the log.
cpan[3]> install DateTime::Format::Strptime
Running insta
1 - 100 of 446 matches
Mail list logo
