in reply to RFC 822 date manipulation without DateTime module?

I haven't used this Perl version of strftime (a C function), but in general convert to gmtime (which takes a trip though Unix Epoch time) and then back to your local time which is what the code above does underneath the covers (or so I think). The time() functions are actually fairly "expensive" in terms of CPU, but unless you have some high performance app, this is the way to go.
  • Comment on Re: RFC 822 date manipulation without DateTime module?

Replies are listed 'Best First'.
Re^2: RFC 822 date manipulation without DateTime module?
by GhodMode (Pilgrim) on Jun 12, 2009 at 12:29 UTC

    I can't use gmtime because it can't use a string like the date specification in an RSS feed. It only takes the number of seconds since the epoch as returned by time (or the shell's date +%s).

    The only real problem is with the text representation of the time-zone. Looking through the time zones used in my feeds, I see that they're using either an offset of UTC, or a three-character representation of the time zone. These are mentioned in RFC 822, but it also says that "time zone may be indicated in several ways".

    The notes for the POSIX strftime function say that the timezone format specifier is notoriously unportable because the timezones are non-standard. That's probably a good reason why it's not built into the core of the language. The (GNU/Linux) shell's date program recognizes every one, though, whether it uses the offset or the abbreviation. 

    --
-- Ghodmode
    Blessed is he who has found his work; let him ask no other blessedness.
    -- Thomas Carlyle
[reply]
      I was just saying the time conversion routines will take a trip through epoch time. That is true for whatever module or library that you use. These things take your text and convert it to a number and then take that number and make new text out of it!

      I found this article on Tech Republic: http://articles.techrepublic.com.com/5100-10878_11-6132371.html

      Basically this local time to gmtime is a mess! I hear that there are some parts of US states that adjust clocks +-30 minutes, not whole hours! The Perl modules will do what the GNU modules will do and maybe even more.

      If you are really interested in "getting it right", I would suggest the Perl date/time module. This thing figures out leap seconds and stuff like that.

      for conversion like from PDT to PSDT, etc, Perl is great at that!

[reply]

        You're right, of course. Date::Time is the right way to do it.

        I'm just trying to minimize external dependencies. It's a hassle to install Perl dependencies. I need root access to use the cpan module or install something using APT. I don't even want to consider how Windows folks would do it.

        I would also need to eliminate the dependence on XML::LibXML (without replacing it with something else external). So, this is probably a wasted effort for me. I'm learning and having fun though :)

        After I'm done with this program, I might try with another language. Perl is still my favorite, but portability and easy installation (or no installation) are my goals. Besides that, I think I have some ideas about how a podcast downloader/client should be that are unique enough to eventually turn this into an open-source project. 

        --
-- Ghodmode
        Blessed is he who has found his work; let him ask no other blessedness.
        -- Thomas Carlyle
[reply]

In Section Seekers of Perl Wisdom