Dual-Life / Time-Piece

Object Oriented time objects
Other
15 stars 33 forks source link

Feature request: Take base object as third argument #49

Open Grinnz opened 4 years ago

Grinnz commented 4 years ago

This idea came about in IRC discussion. Since the underlying OS strptime function allows passing a tm struct and (except on Solaris) will only overwrite the parts of the struct it parses out of the string, it would be nice to provide this capability with Time::Piece. This would provide an alternate solution for both #44 and #48.

my $tm = Time::Piece->strptime($str, $format, Time::Piece::localtime); # parse string as localtime, and use current date as default for any missing components
my $tm = Time::Piece->strptime($str, $format, Time::Piece::gmtime(0)); # current behavior-ish, using UTC and epoch 0 as base
Grinnz commented 4 years ago

There's the question whether this should modify the passed "base" object or just copy its components. I could see either case, in the underlying function it is modified directly, but it's also not really necessary at this level of API and it's more polite to leave inputs untouched. As long as it's documented whether it's modified or not.

scottchiefbaker commented 4 years ago

This is more wordy than #44. Both are decent solutions, I think a simple boolean solution like in #44 would be my preference.

Grinnz commented 4 years ago

The reasons I prefer this solution over the idea in #44 are: It's self documenting - it's not clear what a random boolean argument pertains to; it's more flexible in that it can solve the problem of #48 in a bugwards compatible way, and allow for potentially any other "starting point" object; and it's closer to the underlying strptime API that some may be used to.

Aearsis commented 4 years ago

I would prefer generalizing the behavior for GMT flag (copy unspecified fields from base in $base->strptime(...)). But as this syntax is commonly used to parse localtimes, that would change behavior for a lot of existing code. This solution is a compromise, but an acceptable one.

I would certainly not modify the passed object.

For the starting point, I would suggest inheriting only more significant parts. I would not expect the result of strptime('13.5.', '%d.%m.') to have current time inside. The more when there is no easy way to get localtime with zeroed time... As the behavior of POSIX strptime is kinda undefined wrt initialization of missing parts, I think that this difference is acceptable.