Find every year typed into the site's forms, scripts and settings, and have each one calculated from today's date instead. Then test January bookings and a card expiring years ahead well before the holidays.

No January in the booking form

A guest house on the coast takes bookings through a form on its website. A couple planning a January weekend opens the year menu, and it ends at 2014.

They phone instead, which works on a quiet afternoon. Others simply close the page and book somewhere that lets them choose the date.

The deposit page has the same flaw from the other side. Its card expiry menu also ends at 2014, so it cannot take a card that is valid beyond this December.

Years typed in by hand

When the site was built, someone typed the years into each menu: the year of the build and a few after it. At the time the list looked generous.

Nothing changes those lists as the calendar moves. In the last listed year the booking window shrinks toward December, and in January the menu would offer only years that have passed.

Card menus fail first, because cards are issued for several years at a time. A menu that ends at the current year turns away nearly every card in a guest's wallet.

Staff seldom notice, because they rarely book through their own website.

Where years hide on a site

Years written in by hand turn up in more places than the visible menus:

The fourth and fifth are the hardest to spot, because the form looks fine until a guest submits it and gets an error.

Calculated from today's date

Each of these should be worked out when the page is shown, from today's date: this year and the next two in a booking menu, this year and the ten after it for cards.

A date picker can take its limits as a distance from today, such as eighteen months ahead, rather than as a fixed last day.

Server checks should compare with the current date in the same way, so the form and the server agree about what is allowed.

Done once, by whoever maintains the site, none of these needs touching again at New Year.

Two clocks, not one

A date picker runs in the visitor's browser and reads the visitor's computer clock. Menus built on the server use the server's clock, which may be set to another time zone.

On New Year's Eve, a server set to universal time is already in the new year at four in the afternoon in Vancouver.

A form that mixes both clocks can disagree with itself for a few hours each year. Pick one source of today's date, usually the server, and use it everywhere.

A worked example

A cat-skiing operator in the Interior takes many of its bookings in the fall, for trips from December to April, with a deposit paid online.

In early October, the office noticed that bookings for January to April had stopped arriving through the site, while the phone was busier than usual.

The trip calendar had a last selectable date of December 31, typed into the script's settings years before. The deposit form's card expiry menu ended at the current year.

The developer replaced both with calculated values: trips selectable to the end of the following season, and card years from now to ten years ahead.

The server's own check on trip dates, which also had a fixed last day, was changed to match. A test booking for March, paid with a test card expiring years ahead, went through.

Testing as if it were January

Make test bookings for dates in January, February and next summer, on a computer and on a phone.

Pay a deposit with a test card that expires several years ahead, using the payment company's test mode, and confirm the deposit appears where it should.

To test a date picker, set a test computer's clock to late December, then early January, and see what the calendar offers. Server menus need a test copy of the site with its date changed.

Read the confirmation email for each test booking. A year printed wrongly there misleads the guest even when the booking itself is right.

Check the office side as well: the calendars, rates and reports for next year should exist before the first booking for it arrives.

Before the holidays, not after

Fall is when guests book winter stays, holiday visits and next summer's trips. A form that cannot reach next year turns those guests away just as they arrive.

A guest who meets a form that cannot take their dates seldom reports it. They book elsewhere, and the owner sees only a quiet inbox.

Problems left until January are found by guests first, and by then the menus offer only years that have passed.

The counter-case

Many booking systems already calculate their years, and a payment page hosted by the payment company keeps its own card menu current. A site using both may have nothing to fix.

A guest house that takes every booking by phone and uses its website only for information has no form to worry about.

But the check takes minutes, and a typed-in year often sits somewhere unexpected, in a script setting or a server check. It is worth having whoever maintains the site look before a guest finds it.

Ten minutes before the holiday rush

  1. Open every form that asks for a date or a year.
  2. Look for the last year each menu offers.
  3. Try a date next January and next summer.
  4. Enter a test card that expires years from now.
  5. Ask your developer to search the code for typed-in years.
  6. Replace them with values calculated from today.
  7. Book once more from a phone.

Step five finds what the visible menus hide. A search of the site's code for this year and last year turns up settings and server checks no form test would reveal.

Testing a booking form on the devices guests actually use is also the theme of a booking widget that forgets the time slot on iPhones.

Frequently asked questions

Why can guests not choose a date next year?

The year menu was typed in by hand when the site was built and ends at this year. Nothing updates it as the calendar moves on.

Why does the deposit page turn away valid cards?

Its card expiry menu also ends at this year. Cards are issued for several years at a time, so most valid cards have no matching year.

Where else are years typed into a site?

In date picker settings, booking season end dates, rates tables, server checks that refuse dates past a fixed day, and the copyright line in the footer.

How should the years be set instead?

Calculated from today's date each time the page is shown: this year and the next two for bookings, and this year and the following ten for cards.

Why might the browser and the server disagree about the date?

A date picker reads the visitor's computer clock, while server menus read the server's clock, which may run on another time zone. Use one source everywhere.

When should we test this?

Now, in the fall, before guests book winter and holiday stays. Problems left until January are found by guests first, when the menus offer only past years.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Booking form stuck in this year?

Tell us where your booking form lives, and we will look for every typed-in year before your guests find one.

Start a Conversation