in reply to Re^3: What is the best way to get a list of all Mondays until the end of the year?
in thread What is the best way to get a list of all Mondays until the end of the year?

Sure - but the Mondays we're interested in would probably need to be in local timezone and DST, not GMT. I'm not really sure the code would fail, but I wouldn't bet I get the correct list of dates regardless when the calculation is done either.

I'm not sure the back-and-forth between localtime and gmtime works OK for this calculation - but consider that the Mondays surrounding a DST change date are 7*86400 +- 3600 seconds apart in 'real life' - using 7*86400 instead might place me a day ahead or behind if I'm somehwere near midnight when making the calculation.

Just a warning about the not-at-all-trivial datetime calculations.

Krambambuli
---
  • Comment on Re^4: What is the best way to get a list of all Mondays until the end of the year?

Replies are listed 'Best First'.
Re^5: What is the best way to get a list of all Mondays until the end of the year?
by Rhandom (Curate) on Aug 19, 2008 at 19:20 UTC
    Sure - but the Mondays we're interested in would probably need to be in local timezone and DST, not GMT. I'm not really sure the code would fail, but I wouldn't bet I get the correct list of dates regardless when the calculation is done either
    Turns out they have Mondays in GMT too. :)

    As long as the parsing of the date occurs in GMT and the output of the date happens in GMT, there will be no issues.

    I'm not sure the back-and-forth between localtime and gmtime works OK
    Back and forth between localtime and gmtime will always bite you. Use DateTime if you are doing timezone conversions. However, this problem domain doesn't involve timezone conversions. If the date is parsed using timegm then output using gmtime, there is no issue. It always works.

    Date calculation is not as trivial as people say (or possibly as trivial as my original post says). Date calculation is also not as complicated as other people say. In the case asked for by the OP, using timegm and gmtime as reciprocal functions works just fine and works for date/times in all timezones. The key on this issue is that if you use gmtime, you must parse using timegm.

    To make the issue matter even less in this case the OP is asking for dates - not times. Because we don't care about times - I could've used timelocal/localtime as long as my initial time was normalized to noon because there is no DST timeshift that spans more than 2 hours. I would've used localtime but purists really would've put up a fight then (but it also would've made my code longer :( ).

    In my original code post, I actually don't include any date parsing. Date parsing/converting to time is almost trivial - but not really (you should use DateTime unless you know what you're doing - and maybe even if you do). My code as posted will still give the Mondays till the end of the year. What may go wrong is that because it is based on NOW GMT, it may exclude or included one extra Monday at the beginning of the list based on which Timezone you are in. If you didn't know that by looking at the code then you should use DateTime (there is a theme here - use DateTime).

    Another thing to remember is that epoch time is the same everywhere in the world at the same time because it is based on UTC. So doing integer arithmetic on an operation like the one given is just fine and won't have any issues.

    There are those that will argue that you should always worry about leap seconds and DST - and if you use DateTime you can let it worry about it for you. But if you have a problem domain that doesn't require worrying about those things, you have more options open for solving the problem. Figuring out when or when not to use DateTime is generally easy to do with experience. However, it is almost always easier just to use DateTime.

    my @a=qw(random brilliant braindead); print $a[rand(@a)];
[reply]

In Section Seekers of Perl Wisdom