Making NASA APOD module date safe

[kmpoppe]

Pullrequest

The module now

• calculates "today" at NASA HQ's timezone
• has min/max dates in date-picker control (browser may not support these, but they do no harm)
• min date is 1995-06-16, the day of the first APOD
• 1995-06-17, 18 & 19 are excluded from prev/next buttons because there are no pictures for these three days in the 25+ year history of APOD.
• whether there is a "next" button (+ max date in picker) is now also determined by NASA HQ's timezone.

Issues

• Relates API returns 404 "No data available" when asking for latest date nasa/apod-api#48

Checklist

• None

How2Test

• Open the APOD page between 12am and 6am CET (11pm and 5am UTC) and check that a) a picture is displayed at all, b) the picture is of the correct date ("previous day" seen from CET's day) and c) no "Next" link is displayed.
• Check the date picker does not allow to pick a day before June 16th 1995 and Prev/Next links do not allow to move to June 17, 18 or 19 1995. If any of these three days is chosen from the date picker it should say Could not find a picture for the requested day.

Todo

• None

[coveralls]

Coverage remained the same at 98.105% when pulling 9e2bfc4 on kmpoppe:update-nasa-module into b1d0b92 on jasonmunro:master.

[Yamakasi]

Why are there == used in the compares instead of === ?

[jasonmunro]

Why are there == used in the compares instead of === ?

I prefer == unless I specifically care about type checking so I have no problem with it. What about this specific code would be enhanced with === ?

[Yamakasi]

Why are there == used in the compares instead of === ?

I prefer == unless I specifically care about type checking so I have no problem with it. What about this specific code would be enhanced with === ?

Strict code is advised over less strict, in other words == can be false positive for whatever reason and makes code less good readable / bug tracable when === is really needed. == has no real purpose of usage anymore since years.

[jasonmunro]

Why are there == used in the compares instead of === ?

I prefer == unless I specifically care about type checking so I have no problem with it. What about this specific code would be enhanced with === ?

Strict code is advised over less strict, in other words == can be false positive for whatever reason and makes code less good readable / bug tracable when === is really needed. == has no real purpose of usage anymore since years.

Again, the changes in this PR specifically, are better by using === exactly how?

[Yamakasi]

Why are there == used in the compares instead of === ?

I prefer == unless I specifically care about type checking so I have no problem with it. What about this specific code would be enhanced with === ?

Strict code is advised over less strict, in other words == can be false positive for whatever reason and makes code less good readable / bug tracable when === is really needed. == has no real purpose of usage anymore since years.

Again, the changes in this PR specifically, are better by using === exactly how?

As I explained, no false positives, always strict yes/no. Now you are never sure what happens when the layer below it fails, actually you do but you don't care when you could have cared more.

Consistent coding or not! This is just lazy: oh it's also "good" this way as it works (for now).

[jasonmunro]

Why are there == used in the compares instead of === ?

I prefer == unless I specifically care about type checking so I have no problem with it. What about this specific code would be enhanced with === ?

Strict code is advised over less strict, in other words == can be false positive for whatever reason and makes code less good readable / bug tracable when === is really needed. == has no real purpose of usage anymore since years.

Again, the changes in this PR specifically, are better by using === exactly how?

As I explained, no false positives, always strict yes/no. Now you are never sure what happens when the layer below it fails, actually you do but you don't care when you could have cared more.

Consistent coding or not! This is just lazy: oh it's also "good" this way as it works (for now).

So nothing specific to this PR just more general "it is better". And you seem to be insinuating that I am lazy and don't care. Please don't comment on PRs unless your comment is SPECIFIC to something in the PR, and please keep your comments technical and positive. Thank you.