Editing 2928: Software Testing Day
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.
The edit can be undone.
Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 10: | Line 10: | ||
==Explanation== | ==Explanation== | ||
− | + | {{incomplete|Created by a NEGATIVE ONCE BOOKED EMPLOYEE OF SCAMAZON, BEING PAID EVERY 0 MONTHS - Please change this comment when editing this page. Do NOT delete this tag too soon.}} | |
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 might 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. | 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 might 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. | ||
Line 17: | Line 17: | ||
* The frequency of a recurring event is always expressed as a positive amount of time, so a negative value like “every −1 years” does not make sense. | * The frequency of a recurring event is always expressed as a positive amount of time, so a negative value like “every −1 years” does not make sense. | ||
− | * The first day of the month is the 1st, not the 0th. | + | * The first day of the month is the 1st, not the 0th. |
− | * 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 | + | * 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. |
** 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. | ** 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. | * There are only 60 minutes in an hour, so “71” is too large of a minute. | ||
+ | |||
+ | Legacy systems, especially those running on mainframe, often have daily (or nightly) batches to complete before switching the system date and time. These system are often nestled and interdependent on each other, so if one of the parts is unable to complete its daily run, it is almost always best to let the clock just run on until the error is fixed, and the transition to next business day can occur. Many banks have skipped using date and time on their queue ticket because of this. Their customers (the ones noticing the discrepancy) would make fun of it, and post pictures on social media. Much to the chagrin of the old jurassic banks. The people responsible for testing the software before going live would be blamed for the errors, of course. {{actual citation needed}} | ||
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. | 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. | ||
Line 30: | Line 32: | ||
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. | 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 | + | 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 abused: |
// In Javascript, month 0 is January | // In Javascript, month 0 is January | ||
Line 43: | Line 45: | ||
* 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. | * 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. | * "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, | + | * Japan, in particular, very occasionally uses 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 seldom 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== | ==Transcript== |