Editing 2928: Software Testing Day

{{comic
| number    = 2928
| date      = May 3, 2024
| title     = Software Testing Day
| image     = software_testing_day_2x.png
| imagesize = 255x408px
| noexpand  = true
| titletext = The company tried to document how often employees were celebrating Software Testing Day, but their recordkeeping system kept mysteriously crashing.
}}

==Explanation==
The upcoming holiday Megan is referring to could be Cartoonist Day, which is on May 5th (same day as Mexico's Cinco de Mayo).  As a cartoonist himself, this may be Randall's way of celebrating it.

Quality Assurance (QA) engineers are responsible for ensuring the quality of some product through the use of testing. In software, this process often involves entering bizarre and/or nonsense inputs in an attempt to break the software. Cueball, a QA engineer in this case, expresses concern that the scheduling system doesn't crash. This could either be because as a QA engineer he is concerned about crashes in general, or that as a system used by QA engineers it likely has a lot of weird/invalid values that could cause a crash.

For example, here it seems that Software Testing Day, a day likely celebrated by QA engineers, takes place every &minus;1 years on January 0th at 25:71 PM. That statement is nonsensical in the following ways:

* The frequency of a recurring event is always expressed as a positive amount of time, so a negative value like “every &minus;1 years” does not make sense.
* The first day of the month is the 1st, not the 0th.  (There is an entire ''category'' of bugs/errors which result from numbering systems being mistaken for {{w|Zero-based_numbering|starting with 0 instead of 1}}, or vice versa.)
* There are ({{w|Daylight_saving_time|in most cases}}) only 24 hours in a day, so “25” is (in most cases) too large, and even where there is a switch from Daylight Saving Time, clocks simply repeat the hour before midnight, so the numbers above 24 hours are not displayed, even if using the 24-hour notation.
** In addition, the “PM” suggests that it is a 12-hour time, so the expected range of values for the hour is 1 to 12, making the “25” even more nonsensical.
* There are only 60 minutes in an hour, so “71” is too large of a minute.

Apparently, though this date is nonsensical, the QA engineers have decided to make this date a celebration day. Probably since, as expressed in the comic, the software for keeping track of the date has crashed. Another interpretation of this comic could be how software always crashes in one form or another when being tested, and thus the nonsensical date implies that successful runs of software is never celebrated.

All numerical values are out of range, suggesting that a QA engineer picked this date to test the scheduling system. If the date were to be made sense through under/overflow<!-- is that the right word? -->, it would result on January 1st at 14:11 (2:11 PM). And the -1 year interval could be interpreted to mean it happens every year (perhaps with the annual events being numbered backwards). Alternatively, an attempt to enter these numbers might be rejected as invalid, forcing the user to enter a properly formatted date and time. Both "January" and "PM" are acceptable values; because these two items tend to be selected from predetermined lists since they have an extremely limited number of possible values, it's rarely possible to enter an invalid value for either of these fields.

The title text suggests that the recordkeeping system used to see how often employees celebrated Software Testing Day kept crashing, possibly due to the employees purposefully inputting nonsensical dates or a date that occurred prior to the previous celebration. QA engineers may have semi-accidentally crashed the system by testing it, or deliberately crashed it to disguise the frequency of their days off.

In real life, such invalid dates would be rejected or coerced to be valid dates. Failing to account for invalid dates may result in errors, sometimes catastrophic, such as [https://www.theregister.com/2012/03/12/azure_leap_day_confirmed/ the February 29, 2012 Microsoft Azure outage] caused by the server trying to generate a certificate valid until February 29, 2013, a date that does not exist as 2013 being a non-leap year.

Treatment of invalid dates varies by the chosen programming language and date-time library. Javascript, for example, would coerce January 0th into December 31st, and 25 o’clock into 1 o’clock the following day. While there is no way to directly create a Javascript Date object using 12-hour notation (because that requires text parsing, and the validation of the text input would just result in an invalid date), the following code snippet represents how far this correction can be taken advantage of:

 // In Javascript, month 0 is January
 const d = new Date(2024, 0, 0, 25+12, 71);
 console.log(d); // prints “Mon Jan 01 2024 14:11:00” (exact format depends on your locale)

An event happening every &minus;1 years is equivalent to one that happens every year, but the numbers are reversed; i.e. if this year hosts the 1st Software Testing Day, next year will host the 0th Software Testing Day. This is expected to cause issues in software that assumes that the 2nd Software Testing Day will occur after the 1st Software Testing Day, an assumption that time only moves in one direction that [[2867: DateTime|may or may not]] be reasonable.

The holiday may be due to the claim of "we really can't do anything else, during this automated process", using the same sort of logic as [[303: Compiling]] justified for the programming team. Albeit that here we explicitly learn that a failure behind the scenes will cancel the 'sanctioned' pausing/idling-away of contracted work hours, much as a notable compilation/build error would interupt the others' few minutes of office sports.

===Unusual date-time notation in real life===
* Seconds usually go from 0 to 59. However, when a leap second is added, December 31st, 23:59:59 UTC is followed by 23:59:60 (11:59:60 PM) before starting the new year.
* "24:00" can be used to unambiguously state the ''closing'' midnight of a given date. i.e. the same as "00:00" upon the next, but without the ambiguity as to which 'midnight' bookending of the given date it might refer to, e.g. for deadlines.
** It can be generally used to simplify the understanding of how much time is encompassed by a period starting at a pre-midnight time and ending at a post-midnight one.
* Japan, in particular, [https://media-cdn.tripadvisor.com/media/photo-s/16/7b/00/cd/proof-that-there-are.jpg uses] [https://preview.redd.it/qulk93jj2w731.jpg?width=1080&crop=smart&auto=webp&s=6b8a8abe10579156b853fff140f5f08dce7646f8 hour numbers] greater than 24 to express times past midnight but before sunrise. For example, 25:00 on a Friday is the same time as 1:00 the following Saturday. This is mainly used to express the starting times of midnight TV programming and the closing times of bars and other establishments open late at night. The hours usually go up to 27, but numbers up to 30 (6AM of the following day) are also sometimes seen. It allows the timepoint to 'belong' to the normal working day that precedes it, rather than setting it prior to the normally expected start of business for the day after (especially when that involved weekends).

==Transcript==
:[Megan and Cueball stand facing each other.]
:Megan: So, do you and the other QA engineers have any fun plans for the holiday?
:Cueball: Yeah, assuming the scheduling system doesn't crash.

:[Caption below the panel:]
:Software Testing Day is a holiday celebrated every -1 years on January 0th at 25:71 PM.

{{comic discussion}}

[[Category:Comics featuring Megan]]
[[Category:Comics featuring Cueball]]
[[Category:Programming]]
[[Category:Time]]
[[Category:Calendar]]