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)



Subject: I propose format_datetime should use the time_zone parameter
Download (untitled) / with headers
text/plain 888b
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.
Download (untitled) / with headers
text/plain 1.1k
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.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.