Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the DateTime-Format-Strptime CPAN distribution.

Report information
The Basics
Id: 113568
Status: resolved
Priority: 0/
Queue: DateTime-Format-Strptime
People
Owner: Nobody in particular
Requestors: ALTREUS [...] cpan.org
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Mon Apr 04 12:42:58 2016 ALTREUS [...] cpan.org - Ticket created
Subject: I propose format_datetime should use the time_zone parameter
I don't really think it makes sense for format_datetime to pass through to strftime on the DT object, because this completely ignores the fact the formatter has a time zone on it. To my mind, the whole point of the formatter having a time zone is that it will convert $timezone <-> UTC. Now, the output of parse_datetime is actually a DateTime object that knows it is $timezone, but that seems to me to be functionally equivalent to a UTC object - it's normalised data with sufficient metadata to be converted to any unit. It seems sensible that if the formatter has a time zone specified, the user would want any strings formatted with it to be output based on that time zone. I would argue that is the whole point in the formatter: a container for the metadata required to convert the normalised DateTime object into a representation for output. Currently, it seems to violate POLA.
  Sun Aug 21 18:39:58 2016 DROLSKY [...] cpan.org - Correspondence added
On Mon Apr 04 12:42:58 2016, ALTREUS wrote: Show quoted text
> I don't really think it makes sense for format_datetime to pass > through to strftime on the DT object, because this completely ignores > the fact the formatter has a time zone on it. > > To my mind, the whole point of the formatter having a time zone is > that it will convert $timezone <-> UTC. > > Now, the output of parse_datetime is actually a DateTime object that > knows it is $timezone, but that seems to me to be functionally > equivalent to a UTC object - it's normalised data with sufficient > metadata to be converted to any unit. > > It seems sensible that if the formatter has a time zone specified, the > user would want any strings formatted with it to be output based on > that time zone. I would argue that is the whole point in the > formatter: a container for the metadata required to convert the > normalised DateTime object into a representation for output. > > Currently, it seems to violate POLA.
Using this module to format DateTime is almost entirely pointless. DateTime itself implements a strftime method. Just use that instead, or better yet use the CLDR formatting, which gives you a lot more options.
  Sun Aug 21 18:39:59 2016 The RT System itself - Status changed from 'new' to 'open'
  Sun Nov 13 16:14:19 2016 DROLSKY [...] cpan.org - Correspondence added
Ticket migrated to GitHub as https://github.com/houseabsolute/DateTime-Format-Strptime/issues/7
  Sun Nov 13 16:14:35 2016 DROLSKY [...] cpan.org - Status changed from 'open' to 'resolved'