See Overpass_API/Overpass_API_by_Example#OSM_data_at_a_certain_date for a query example displaying state of OSM database at a specific date
See Overpass_API/Overpass_QL#date for language documentation how to access Attic Data in an Overpass API query.
Attic Data refers to the "invisible" data of the versions of OSM data older than the recent one, including versions of now deleted objects. On the OSM website it can be found behind the "history" link every object has. The term "Attic Data" stems from CVS-terminology and there referred to data which was not really needed anymore but still kept to maybe return the system to the consistent state of an earlier date.
"It is on purpose not named 'historical'. It would have become a homonym, and having homonyms is always asking for trouble.
There is a whole project, named OpenHistoricalMap that collects data of
features that have existed in human history, like Roman streets. That's
history. It's a firm definition we cannot and should not overturn. In
particular, OpenHistoricalMap does use for a good reason tags like
start_date and end_date independent of when a representation is written
to the database.
What we have here are 'outdated representations' of more or less
unchanged objects on the ground. It may sometimes reflect changes on the
ground, but most of changes happen due to mapping refinement or
vandalism. Hence, we need a different notion to express that we refer to
representations that were current at an earlier point in time.
It is then indeed reused from the well-known VCS terminology: a VCS
keeps as well the extra data necessary to turn the controlled system
back to consistent state at an earlier date. That kind of data is called
"attic" there, and it is precisely the same concept as we have here.
A fun fact: the whole attic feature of Overpass is designed on the same
decisions as the CVS storage. It turns out to be quite useful. We are as
disk-space-constraint now as the users were for source code at the time
CVS was developed in 1990."