If you only have a year and day of year, then having a from_day_of_year
constructor saves a _lot_ of calculation that end users have to do. OTOH,
having to do 'DateTime->now(time_zone => "local")' isn't very onerous at
all.
If you need an example DT::F::ISO8601 makes heavy use of from_day_of_year().
I was thinking of end-user code more than DT-related library code. But I'm not really arguing against having from_day_of_year() anyway. I'm arguing for a simpler way to get the current local time because, IME with DT and other date libraries, this is a *very* common task.
Heck, if the API Stability Gods of the 0.1x Phase of Development could somehow be appeased, I'd argue that now() should actually default to time_zone => 'local' because that's what users will expect--and what now() "sounds like" to me. But I suspect the Gods will not be appeased, thus the localtime() compromise.
C'mon, it's one innocent little line... :)
sub localtime { shift->now(time_zone => 'local', @_) }
Is this the horrid face of code bloat, or an honest effort to address a common usage scenario?
Besides, I thought the whole point of not having a single new() constructor that understands many kinds of args was that creating specialized constructors was a cleaner way to add such functionality. And now we're balking at actually using this mechanism to add a constructor whose usage, IMO, will be second only to new() in end-user code?
-John
