Correct. When I needed to get the epoch time value of "some random sunday" for testing, Date::Manip was the first thing that came to mind.
1) My system is central US time, the test box I installed to is PHT (Phillipines), and I'm not sure whether the one it's failing on is using PHT or German time. Fun, no? But you're right - I had been assuming all operations would be in the machine's local time, regardless of what that may be. Is there a more reliable way to say "give me a time value for a day that is a Sunday/Tuesday in the current time zone"?
2) The provided UI mockup included 7 checkboxes to indicate weekday/weekend status independently for each day, implying that the sets need not be contiguous. Su,Tu,Sa = weekend / M,W,Th,F = weekday doesn't work with a begin/end range. | [reply] |
I think you want to use Date_DayOfWeek then, so something like Date_DayOfWeek(UnixDate(ParseDate('last saturday'),'%m', '%d','%y'))
| [reply] [d/l] |
What would be the advantage of using that rather than (localtime ($date))[6]? The only differences I see, based on the Date::Manip docs, seem to be whether the date is specified in epoch seconds or as m/d/y and whether Sunday is considered to be day 0 or day 7.
If there is an advantage, I can definitely switch, but I personally prefer to handle dates internally as epoch times and, in this case, to use localtime to get the day of week directly from that value rather than converting the epoch time to m/d/y so that m/d/y can be given to Date_DayOfWeek. I suppose I don't want to change it without knowing why I'm changing it.
| [reply] [d/l] [select] |