National Rail Enquiries; calendar glitch.

[Peter Mugridge]

A rather interesting glitch tonight on the calendar on the NRE site is making it impossible to select correct dates to match up with timetables.

See the picture attached; it's still the April image but it's labelled May. Scroll to the next calendar page and it's the May calendar but is labelled June, and clicking on, say, the 2nd causes it to enter the date 02/06/2016 in the search box.

However, on the April labelled as May as in the picture below, it is not possible to click on any date earlier than the 30th.

A curious glitch, but one which could potentially see the unwary booking tickets for the wrong month!

 

[Ambient Sheep]

Speaking as a software engineer (albeit not one who does web stuff), this sounds to me like a glitch caused by the fact that it's now summer time and your query was within the first hour of the new month.

At the time you posted, 00:39, it was May as far as current summer time was concerned, but still April as far as GMT/UTC was concerned. I haven't checked, but I'm guessing that now it's gone 01:00, it's now ok again, as it's May all round...

I suspect that the same thing probably happened between 00:00 and 00:59 on April 1st, and that, if the bug isn't fixed, it will continue to do so on the first of every month until 1st October inclusive. November to March should be ok.

I first came across this sort of thing when I was fixing somebody else's code back in the early 1990s. Due to a combination of what was arguably a bug in Microsoft's C library, and my rather naive predecessor, the software he left us was computing March as having only 30 days, and October as having 32... *facepalm*

Date & time handling is always a bit of a nightmare for us software types; summer-time handling doubly so. Still not much excuse for this though, that's what testing is for!

 

[Peter Mugridge]

Oh that's interesting - so this might happen for an hour every month at that time until we revert to proper time ( GMT ) in the autumn?

 

[Ambient Sheep]

Yup! Unless they fix it first...


EDIT: Or, given how tricky these things can be to fix (in my experience such bugs are either ridiculously easy to fix or require a horrendous rewrite from the ground-up), they could just be cheeky and take the whole website "down for maintenance" between 23:45 on the last day of the month and 01:15 on the first day of the month during the summer! :-P

 

[route:oxford]

Date & time handling is always a bit of a nightmare for us software types; summer-time handling doubly so. Still not much excuse for this though, that's what testing is for!

Don't forget to throw the US presentation of dates into the mix as well...

That's a real nightmare when someone just grabs a bit of code thinking it'll do. My professional body had a real issue when an errant bit of code resulted in CPD being recorded against the wrong date. Where the day was under 12 and the month was also under 12, the day and month were *sometimes* transposed -if the user had a browser set to English (US).

 

[fairysdad]

Don't forget to throw the US presentation of dates into the mix as well...

That's a real nightmare when someone just grabs a bit of code thinking it'll do. My professional body had a real issue when an errant bit of code resulted in CPD being recorded against the wrong date. Where the day was under 12 and the month was also under 12, the day and month were *sometimes* transposed -if the user had a browser set to English (US).

Sounds like an ambiguity in the user input; some (programming) languages will have a setting in which you use a / for US-formatted dates (5/1/16) and a - for GB-formatted dates (1-05-16), and it'll work out the date from there Of course, the best option is to use ISO-8601 formatted dates (2016-05-01), or a timestamp (1462142181) - although the latter is really only good from a data storage point of view and not for user input/output!

 

[Bantamzen]

Sounds like an ambiguity in the user input; some (programming) languages will have a setting in which you use a / for US-formatted dates (5/1/16) and a - for GB-formatted dates (1-05-16), and it'll work out the date from there Of course, the best option is to use ISO-8601 formatted dates (2016-05-01), or a timestamp (1462142181) - although the latter is really only good from a data storage point of view and not for user input/output!

Oh don't get me started on dates and US written languages. Many a fun time re-coding to handle the different formatting. Generally speaking if storing dates I'll always convert to a timestamp, then let the output code handle the formatting. Saves a lot of shouting and swearing when de-bugging!!