Closed autarch closed 4 years ago
From josh@hoblitt.com on 2019-10-09 19:21:29 :
It was probably not a format explicitly listed in the spec but I think it should be a supported format. A PR would be gladly accepted.
From domm@cpan.org (@domm) on 2019-10-09 19:39:56 :
Hi!
On Wed, Oct 09, 2019 at 03:21:29PM -0400, Joshua Hoblitt via RT wrote:
It was probably not a format explicitly listed in the spec but I think it should be a supported format. A PR would be gladly accepted.
ok, great, than I'll prepare one.
Is there a git repo of the code somewhere? I couldn't find it linked from the metacpan page...
Greetings, domm
--
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
From josh@hoblitt.com on 2019-10-09 19:41:09 :
Yes, the metadata needs to be updated. https://github.com/jhoblitt/DateTime-Format-ISO8601
From drolsky@cpan.org (@autarch) on 2019-10-09 20:12:25 :
On 2019-10-09 14:15:48, DOMM wrote:
Hi!
Is there any reason that there is support for
YYYY-MM-DDThh:mm:ss[+-]hh:mm YYYY-MM-DDThh:mm:ss[+-]hh YYYY-MM-DDThh:mm:ss.ss[+-]hh:mm
but NOT for YYYY-MM-DDThh:mm:ss.ss[+-]hh
i.e. a string with miliseconds and only an hour offset is not parsable:
perl -MDateTime::Format::ISO8601 -E 'say DateTime::Format::ISO8601-
parse_datetime("2019-10-09T21:07:10.42+02")'
PostgreSQLs now() functions returns strings with fractions of seconds and an hour only time-zone:
select now(); 2019-10-09 21:10:21.14294+02
I guess it wouldn't be too hard to implement, and I would supply a patch, if this format would be supported...
Greetings, domm
I have no particular objection but I would note that there is a DT::F::Pg distro that might be a better choice if you just need to handle data from Pg.
From domm@cpan.org (@domm) on 2019-10-09 21:06:52 :
Hi!
On Wed, Oct 09, 2019 at 04:12:26PM -0400, Dave Rolsky via RT wrote:
I have no particular objection but I would note that there is a DT::F::Pg distro that might be a better choice if you just need to handle data from Pg.
Well, actually the data is coming from a REST API that is backed by Postgres. And the API takes the string coming from postgres, does s/ /T/ to "convert" from RFC3339 to ISO8691, and passes the string on via JSON. And this string might contain fractional seconds with only an hour offset...
Hence this feature request, which I will implement tomorrow.
Greetings, domm
--
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
From domm@cpan.org (@domm) on 2019-10-10 11:21:56 :
Merged https://github.com/jhoblitt/DateTime-Format-ISO8601/pull/3 from domm
Migrated from rt.cpan.org #130682 (status was 'open')
Requestors:
From domm@cpan.org (@domm) on 2019-10-09 19:15:48 :
Hi!
Is there any reason that there is support for
YYYY-MM-DDThh:mm:ss[+-]hh:mm YYYY-MM-DDThh:mm:ss[+-]hh YYYY-MM-DDThh:mm:ss.ss[+-]hh:mm
but NOT for YYYY-MM-DDThh:mm:ss.ss[+-]hh
i.e. a string with miliseconds and only an hour offset is not parsable:
perl -MDateTime::Format::ISO8601 -E 'say DateTime::Format::ISO8601->parse_datetime("2019-10-09T21:07:10.42+02")'
PostgreSQLs now() functions returns strings with fractions of seconds and an hour only time-zone:
select now(); 2019-10-09 21:10:21.14294+02
I guess it wouldn't be too hard to implement, and I would supply a patch, if this format would be supported...
Greetings, domm