Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the DateTime CPAN distribution.

Report information
The Basics
Id: 114496
Status: rejected
Priority: 0/
Queue: DateTime
People
Owner: Nobody in particular
Requestors: PHILKIME [...] cpan.org
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Thu May 19 14:27:46 2016 PHILKIME [...] cpan.org - Ticket created
Subject: Loss of information with missing month/year
Currently, DT doesn't seem to be able to distinguish between missing and default months/days: use DateTime::Format::ISO8601; my $dt = DateTime::Format::ISO8601->parse_datetime('2016'); say join(',', $dt->year, $dt->month, $dt->day); my $dt = DateTime::Format::ISO8601->parse_datetime('2016-01-01'); say join(',', $dt->year, $dt->month, $dt->day); both output the same thing (2016,1,1). Could there be a couple of get methods that would return undef for missing month/year in the input or is this caused by the Format modules? It's a bit of a pain as when one has the resulting DT object, one has lost information about the source data.
  Thu May 19 14:51:23 2016 DROLSKY [...] cpan.org - Correspondence added
On Thu May 19 14:27:46 2016, PHILKIME wrote: Show quoted text
> Currently, DT doesn't seem to be able to distinguish between missing > and default months/days: > > use DateTime::Format::ISO8601; > my $dt = DateTime::Format::ISO8601->parse_datetime('2016'); > say join(',', $dt->year, $dt->month, $dt->day); > my $dt = DateTime::Format::ISO8601->parse_datetime('2016-01-01'); > say join(',', $dt->year, $dt->month, $dt->day); > > both output the same thing (2016,1,1). > > Could there be a couple of get methods that would return undef for > missing month/year in the input or is this caused by the Format > modules? It's a bit of a pain as when one has the resulting DT object, > one has lost information about the source data.
Sounds like you want https://metacpan.org/release/DateTime-Incomplete That said, getting the parser to return an incomplete object is probably not a trivial patch, and would need to be made optional, rather than the default.
  Thu May 19 14:51:24 2016 The RT System itself - Status changed from 'new' to 'open'
  Thu May 19 16:24:31 2016 PHILKIME [...] cpan.org - Correspondence added
You know, I think we had this discussion a few years ago and I'm just returning to the topic as I have another reason to need ISO8601 support. DateTime-Incomplete didn't do it either as I recall but I can have another look. I don't think this needs to make the parser return anything incomplete, just a couple of methods to at least flag that month/day were defaulted from missing values otherwise "2016" and "2016-1" and "2016-1-1" give the same objects and this loses information which in my application at least, is crucial. On Thu May 19 14:51:23 2016, DROLSKY wrote: Show quoted text
> Sounds like you want https://metacpan.org/release/DateTime-Incomplete > > That said, getting the parser to return an incomplete object is > probably not a trivial patch, and would need to be made optional, > rather than the default.
  Thu May 19 16:37:23 2016 PHILKIME [...] cpan.org - Correspondence added
Something like the Date::Manip::Date ->complete() method. This was implemented precisely because the author couldn't find any module not losing this information apparently.
  Sun Aug 21 18:11:24 2016 DROLSKY [...] cpan.org - Correspondence added
On Thu May 19 16:37:23 2016, PHILKIME wrote: Show quoted text
> Something like the Date::Manip::Date ->complete() method. This was > implemented precisely because the author couldn't find any module not > losing this information apparently.
Looking at the DateTime::Incomplete docs, it really seems like it does all of this. As I said, the trick would be getting the parser to return an incomplete object. Once you have that, it has all the methods needed to figure out which fields are populated and which are not. Given that, you could then generate an actual DateTime object with defaults filled in. Regardless, I don't think this is a bug related to DateTime.pm itself. DateTime.pm only implements complete datetimes. I don't think that changing this is really possible. If I were to do it all over again, I'd probably package up something like DateTime::Incomplete with DateTime itself and encourage parser authors to make use of it more liberally. I'm going to close this bug, but you could open a new one against DateTime::Format::ISO8601 asking it to return DateTime::Incomplete objects (maybe optionally). Of course, DF::F::ISO8601 could probably use some additional love, maybe from a motivated new maintainer ...
  Sun Aug 21 18:11:30 2016 DROLSKY [...] cpan.org - Status changed from 'open' to 'rejected'