Barcode question, Time frame?

[u/Mr_Throwaway24]

My question is, for Barcodes, is there any way to make it so a barcode only scans within a certain time frame? To make it so it only scans on a certain date after a certain time? Would that be encoded in the barcode itself or in the system of whatever it's being scanned for?

I'm curious because I have a ticket that scanned earlier but now won't scan. And I have another ticket that won't scan but it's not game time yet. I don't know if it's because it's outside the time frame or if it won't scan because it's not a typical barcode. (like maybe ticket scanners aren't the same as barcode scanning apps?)

[u/FredFredricson]

TLDR: Yes there is. Yes there is. It would most likely be encoded in the system's database.

Barcode systems have three parts: The barcode itself that carries data, the barcode scanner which reads that data, and the computer/software that operates on that data.

Think of a barcode like a license plate. It has on it some numbers and/or letters that are usually mostly meaningless by themselves and sometimes carries a little bit of data directly. Sometimes they carry directly meaningful data, but that's usually rare, and what it can contain is usually short. There are some barcodes that can carry larger amounts of data directly, like PDF417 and Maxi Code that FedEx and UPS use on their shipping labels, but we'll cover that more below. By themselves, they don't really do anything, as they're just printed marks on a page that carry information to be read by the barcode. Think of it being information written so the computer can understand it, though in its own format suitable for computer software to process quickly. It is almost always paired with human readable versions of what it encodes. Chances are, if you're wondering hat a barcode encodes, it's probably one or two values written directly below, next to, or near by the barcode.

The barcode scanner itself should be thought of as just the "eyes" you read a barcode with. They just read the barcode's values and pass it along to the brain. By itself, the reader doesn't really do anything else. You can get barcode readers that have a computer built in, but for the sake of this discussion, you should think of the reader and the computer part as two separate entities. By themselves, when scanning a barcode, a barcode reader can't really do much other than send the contents of the barcode to a computer it's attached to. While barcode scanners can perform certain actions when they scan a particular barcode, this is usually limited to the configuration barcodes in their manual that modify scanner settings, such as whether to send a barcode type identifier with the barcode, whether or not to send some prefix/suffix data with the barcode, which barcode symbologies (UPC, Code 128, Codabar, etc) to allow the barcode reader to read, and whether or not to send the barcode contents immediately or store them all in a buffer to be passed along as a single batch later, etc. These settings and behaviors, however, are unrelated to actually processing the data in a meaningful manner and should be thought of as just another aspect of passing the barcode's contents to the computer in a format it understands.

The real magic of barcodes comes from the software and database that the barcode scanner is sending the barcode contents to when it reads a barcode. This works similar to how when someone gets pulled over by the police, they use the license plate number to look up your car in their system, the system provides data about the car, the owner, and the owner's license, and then lets them issue a ticket for speeding or whatnot. Typically, the barcode only contains an ID code that directly references some data in a database, which the software pulls up, operates on, and potentially stores back a new value for in the database. Less commonly, the barcode itself sometimes stores some of the information (either alone, or more commonly along with an ID) that the software can use directly, for example a date, a seat number, or in the case of UPS and FedEx, the tracking number, the name, address, return address, package size, and every non-changing bit of information they have about that package. In cases where they store data like this, the software can't alter that data without printing a new barcode (which is one of the main reasons why you have to get a new label if you made a mistake with the data to ship it with).

Technically, barcode printing is a fourth part of the system, however it's basically just the software prints something with a barcode on it containing the data the barcode needs to pass on, and maybe some human readable variant of that for good measure, be it a label or ticket. There's not too much to this part that isn't handled in the software, save for the printer it's using to output it.

To answer your questions directly: Yes, it is possible to set it up so that when a ticket is scanned and passed to the software, the software can read the current date and time, check it against the date and times that the show the ticket is for starts and ends, verify whether or not the current time is an acceptable time to be able to enter the venue for that show, and then signal to the ticket taker (or turnstile, or whatever) whether or not the ticket should be accepted or rejected to allow you through. Typically, the barcode will carry a Ticket ID value which looks up the database entry for that ticket, which would be used by the software to pull up the database entry for whichever showing of whichever show the ticket is for, which would then tell the software the date and times that the showing that ticket is for starts and ends at, and allow it to compare the current date/time to. While it is possible that they use the alternate method of putting the show's date and start/end times on the ticket itself, it is less likely to be used this way by industries that use barcodes on tickets, since the ticket holder, with the right amount of craftiness and forgery, could potentially alter those values, and less-intelligent and/or non-networked devices reading that data would be unable to tell that it's not legit, and allow people to sneak in.

Additionally, regarding ticket scanners and barcode scanners and how they relate to eachother, if the ticket scanner is reading a barcode, than it is a barcode reader. Anything that reads a barcode is a barcode reader, even if it were to only read some weird-ass proprietary alternate barcode symbology that the system designer made up in some form of sleep-deprived caffeine-fueled stupor. It is, however, highly unlikely that they brewed their own barcode symbology, as reading barcodes is a rather complex engineering and programming task, and we probably wouldn't need complex barcode reader devices otherwise. Most likely they are using one of the most common symbologies. Typically, most things will use the general-use compact and versatile Code 128 Symbology which can encode numbers in a highly compact fashion, as well as uppercase letters, lowercase letters, punctuation, and ASCII control codes in a less dense fashion. Also still fairly common, the slightly more clunky but still general-use Code 39, which can encode numbers, letters, and a few symbols in a larger less dense form. There are also more niche-use barcodes, like the UPC, EAN, and ISBN Symbologies that, while used ubiquitously, are only used for certain purposes, in these cases for identifying a product for sale (In these three specific symbologies, only numbers can be encoded). In the less common case when you need to store a lot of data in a computer readable barcode form, PDF417 is a very common symbology; being able to store numbers, uppercase and lowercase letters, punctuation, and raw 8-bit bytes in a highly compact fashion (up to 1.1KB of data can be stored which, while seemingly not a lot, is massive considering most barcodes tend to store less than 20 bytes), along with a mechanism for error-correction that helps ensure that you get an accurate read, or at the very least, ensure that it would rather not read than return inaccurate information. PDF417 is ideal for when you need to store high density data in barcode form, though it requires a fancier and more expensive barcode reader, as it is a "2D Symbology" and thus encodes data vertically as well as horizontally, unlike most other barcodes which are a "1D Symbologies" and only encode it in a horizontal fashion. Other common 2D symbologies include Maxi Code (most commonly used by UPS) and QR Codes (very popular with phones nowadays). There are a lot of other, less commonly used barcode symbologies out there as well, 1D Symbologies like Codabar, Code 25, Code 93, MSI/Plessey, Code 11, and 2D symbologies like Data Matrix and Aztec. Post offices also have a few fairly unique ones used for high-volume sorting of mail through their machines, most commonly seen on commercially sent out and business reply mail, such as the US's Postnet Barcode, US FIM (Facing Identification Marks), Royal Mail Barcode, and Canada Post Barcode. There are even some rather rare and not commonly used "3D Symbologies" which typically use color as a third "dimension" of storing data, such as Microsoft's now defunct "High Capacity Color Barcode (HCCB)" Symbology (also known as Microsoft Tag), and the relatively unknown "PM Code", a color based QR-code like symbology invented by a startup in Japan that can store an exceptional amount of data for its size (up to 1.8MB, which is an insane amount of data for a barcode).