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: 102837
Status: resolved
Priority: 0/
Queue: DateTime
People
Owner: Nobody in particular
Requestors: awilliam [...] redhat.com
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Tue Mar 17 18:15:09 2015 awilliam [...] redhat.com - Ticket created
Subject: datetime() / iso8601() method discards timezone information
Date: Tue, 17 Mar 2015 15:14:55 -0700
To: bug-DateTime [...] rt.cpan.org
From: Adam Williamson <awilliam [...] redhat.com>
I noticed that datetime seems to have no way to produce an ISO8601 string with a timezone offset. When you do web searches for this you find multiple places where people have reinvented essentially the same fairly trivial function to stuff the timezone offset on the end of the output of datetime() / iso8601(). A patch to include this was submitted before but rejected: https://rt.cpan.org/Public/Bug/Display.html?id=83689 I find the rejection strange, however. The cited reason is: "since the time zone is specified in a way that loses info" however, isn't the current code losing way *more* information? A datetime object will often have a timezone explicitly specified. Surely simply entirely throwing it away when producing an 'ISO8601' representation of that date/time is losing more information than representing it with a slight loss of detail? Almost more importantly, note that per ISO8601, a string with no TZ offset is not considered to have an 'unknown' timezone, but is considered to be for the 'local' timezone, whatever that may be in context. Effectively, when I call 'iso8601' on a datetime object which has a specific timezone, the timezone is entirely thrown away, and the resulting string is a valid ISO8601 string but one which clearly does not accurately represent the datetime object from which it was produced. Surely it's better to represent the timezone with a slight loss of precision than it is not to include it at all? Obviously the existing behaviour has been around sufficiently long that it would probably need to remain the default, but it should at least be possible to obtain a more correct outcome via a parameter or similar. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net
  Sun May 31 16:22:33 2015 DROLSKY [...] cpan.org - Correspondence added
On Tue Mar 17 18:15:09 2015, awilliam@redhat.com wrote: Show quoted text
> I noticed that datetime seems to have no way to produce an ISO8601 > string with a timezone offset. When you do web searches for this you > find multiple places where people have reinvented essentially the same > fairly trivial function to stuff the timezone offset on the end of the > output of datetime() / iso8601(). > > A patch to include this was submitted before but rejected: > > https://rt.cpan.org/Public/Bug/Display.html?id=83689 > > I find the rejection strange, however. The cited reason is: > > "since the time zone is specified in a way that loses info" > > however, isn't the current code losing way *more* information? A > datetime object will often have a timezone explicitly specified. > Surely simply entirely throwing it away when producing an 'ISO8601' > representation of that date/time is losing more information than > representing it with a slight loss of detail? > > Almost more importantly, note that per ISO8601, a string with no TZ > offset is not considered to have an 'unknown' timezone, but is > considered to be for the 'local' timezone, whatever that may be in > context. > > Effectively, when I call 'iso8601' on a datetime object which has a > specific timezone, the timezone is entirely thrown away, and the > resulting string is a valid ISO8601 string but one which clearly does > not accurately represent the datetime object from which it was produced. > > Surely it's better to represent the timezone with a slight loss of > precision than it is not to include it at all? > > Obviously the existing behaviour has been around sufficiently long > that it would probably need to remain the default, but it should at > least be possible to obtain a more correct outcome via a parameter or > similar.
Or you could do as I suggested in the previous ticket, and use DateTime::Format::ISO8601. I really should have just left this method as being called "datetime()" and never called it "iso8601()". I've added a note in the docs pointing people to the format module for proper ISO8601 formatting.
  Sun May 31 16:22:33 2015 The RT System itself - Status changed from 'new' to 'open'
  Sun May 31 16:22:46 2015 DROLSKY [...] cpan.org - Status changed from 'open' to 'resolved'
  Sun May 31 16:27:11 2015 DROLSKY [...] cpan.org - Correspondence added
Hmm, then I realized that DT::Format::ISO8601 is only a parser and doesn't do formatting :( That module could really use an active maintainer to add things like formatting ...