in reply to Re: date and time using localtime
in thread date and time using localtime

Using one of the time related modules to load strftime offers no advantage over the OP's choice of POSIX for the code shown. Perhaps he needs other features of POSIX. I was unaware that the function could be called as a method. Many readers would consider that an advantage.
Bill

Replies are listed 'Best First'.
Re^3: date and time using localtime
by haukex (Archbishop) on Oct 08, 2017 at 08:37 UTC
    Using one of the time related modules to load strftime offers no advantage over the OP's choice of POSIX for the code shown.

    If we're only talking about the strftime "...", localtime bits of code, then yes, there isn't a big difference. But otherwise I disagree. In the OP's code, note how they add 1900 to the year, but don't change $mon, which is zero-based - an easy thing to overlook; both Time::Piece and DateTime return the month as the more natural 1-based. Also, in my experience, one date/time task seldom comes alone - if the OP decides they want to display the date in different locales, or different time zones, or do any kind of math, DateTime handles that easily and correctly.

    I was unaware that the function could be called as a method.

    Time::Piece overrides localtime and gmtime to return an object.

Re^3: date and time using localtime
by Anonymous Monk on Oct 07, 2017 at 20:28 UTC

    Using one of the time related modules to load strftime offers no advantage over the OP's choice of POSIX for the code shown. Perhaps he needs other features of POSIX. I was unaware that the function could be called as a method. Many readers would consider that an advantage.

    What?