Printable View
It is possible to prevent delivery selection of saturday and sunday by the above blocked statement; however, Direction is a number representing how many calendar days forward of today to allow the next delivery. Basically in your case, if today is Saturday, Sunday, early Monday or late Friday then the direction is 5, otherwise 7.Quote:
Originally Posted by kimono
Thank you very much.Quote:
Originally Posted by mc12345678
I am sorry that the reply was delayed.
Is there a way to judge direction is 5, otherwise 7?
More research is needed, but in the basic sense, additional javascript code can be used to provide a result of 5 or 7 depending on the result of the javascript method: getDay()Quote:
Originally Posted by kimono
The problem with the above is that it uses 5 for any time during Monday and Friday, not just after some cut-off time. Further, the function responds based on the date/time of the user not the store. So in the extreme case of a store being on one side of the date line, a customer on the other side may be offered a delivery time period outside of the expected/allowed time frame or may be provided a date that is sooner than possible. Additional date/time comparison would be needed to say make the comparisons on the left more "realistic" to your business if you deal with people outside of your central location. If they are local, then say where curDay == 1 && curTime < Mondays_cut_off_time would be what is needed, though would have to also identify/determine what Mondays_cut_off_time would be. The same would be needed for Friday but a little in reverse: curDay == 5 && curTime >= Fridays_cut_off_time. Oh, also would need to set/determine curTime... again more research would be needed on my side or as someone else offers up.Code:todayDate = new Date();
curDay = todayDate.getDay();
Direction : (curDay == 0 || curDay == 1 || curDay == 5 || curDay == 6) ? 5 : 7);
Also, if additional "tests" are added as described, things like curDay == 1 && curTime < Mondays_cut_off_time would need to be surrounded by parentheses. So that the two pieces would be treated as one test.
Also, it is fine if only Saturday and Sunday, but it seems to be unable to deal with holidays and other holidays.
Thank you very much for your prompt response.Quote:
Originally Posted by mc12345678
It seems that response other than holidays on Saturdays and Sundays alone seems to be difficult only with the above answers.
By the way, if it is judged by time, it may not be beautiful,
direction: <?php (strtotime(date('H:i:s')) < strtotime('10:00:00')) ? 5:7; ?>
I feel like I can cope if I do.
Take a look at the example in: includes/modules/pages/checkout_shipping/jscript_calendar_head.phpQuote:
Originally Posted by kimono
It contains an example of two "dates" being blocked out for one entry. The first example is an actual and specific date, the second is more generic, but they are contained within square brackets with a comma between. To then factor that/those in as well to achieve the most flexibility for the customer, the holiday would have to be "considered" within the direction determination. Ie. A Monday holiday with a today date being Thursday means that the delivery has to be pushed out an additional day. If nothing else, welcome to computers and date/time keeping. :P sorry, some of the issues surrounding dates are not the easiest to resolve. There may be some additional "plugin" out there that could do this part of the calculation and provide a modified future number. Or perhaps a different date script could do it more "automatically"; however, capturing a lot of that request requires additional "work".
Right, so, again, using php provides date/time of the server. Using javascript basically uses the date/time of the computer accessing the site... working around that is where I was indicating addition review would be necessary. Wanted to at least get you started on looking, thinking, etc...Quote:
Originally Posted by kimono
I'm sure I overthink it, but another concern/consideration of using php time (the "exact time" instead of a timezone) is that if a page is opened either near the end of the time period or just before the start, when the javascript processes to show the available options, the information is hard-coded and not flexible to the users time. Works in their favor just before the cut-off on Friday, but hurts them if they start just before the late Monday time.
Then there is also the effect of opening another tab for the site such that the session remains active while they "investigate" or otherwise navigate the site to eventually come back to the checkout section. Again, generally want to keep that as fluid as possible. Now the php time and timezone could be hardcoded as part of the comparison such that the user's date/time is converted to the same as your server and then compared to that value... That way at least you don't have to capture their time, just "show" them "yours" and let the software complete the comparison.
Then as for the "holidays" basically need to evaluate future holidays to see if they fall within the applicable span and if they do, add that many holiday days to the result... at least that's what I just considered, though may require more consideration.
thank you for your answer.
If there are any good ideas, thank you.
If you find something here, I will contact you.