INT 1Ah AH=04h reads the date kept by the CMOS clock: the century in CH (19h or 20h), the year within it in CL, the month (01h..12h) in DH and the day of the month in DL, all BCD. The weekday the chip also keeps is not returned; DOS computes its own (INT 21h AH=2Ah).
MOV AH, 04h ; BIOS: read the RTC dateINT 1Ah ; CH = century, CL = year, DH = month, DL = dayJC FAIL1MOV BX, DX ; keep month and day: printing uses DLMOV AL, CHCALL PHEX2 ; "20"MOV AL, CLCALL PHEX2 ; "26": the year in two BCD bytesMOV DL, "-"MOV AH, 02h ; DOS: print the character in DLINT 21hMOV AL, BHCALL PHEX2 ; the monthMOV DL, "-"MOV AH, 02h ; DOS: print the character in DLINT 21hMOV AL, BLCALL PHEX2 ; the dayJMP DONE1FAIL1:MOV DX, OFFSET STOP1MOV AH, 09h ; DOS: print the $-string at DS:DXINT 21hDONE1:STOP1 DB "the clock is not running$"PHEX2 PROC NEAR ; print AL as two hex digits; keeps every registerPUSH AXPUSH CXPUSH DXMOV DH, AL ; keep the byteMOV CL, 4SHR AL, CL ; the high nibbleCALL HEXN1MOV AL, DHAND AL, 0Fh ; the low nibbleCALL HEXN1POP DXPOP CXPOP AXRETHEXN1:ADD AL, "0"CMP AL, "9"JBE HEXN2ADD AL, 7 ; past "9": "A".."F"HEXN2:MOV DL, ALMOV AH, 02hINT 21hRETPHEX2 ENDP
The century
The MC146818 itself only counts years 00..99. The century byte is a convention of the IBM AT's CMOS layout (address 32h), maintained by the BIOS, and some old BIOSes did not roll it over at the end of 1999: they reported 1900 for 2000. That is the "Y2K" BIOS problem, and why careful programs treat a year below 80 with century 19h as 20xx. DOS does the same internally, since its own date starts at 1980.
Pitfalls
As with the time, there is no RTC before the AT. The date only advances while the machine runs or the battery lasts; DOS's date, advanced at midnight from the tick count, can drift away from it if a program swallows the midnight flag of INT 1Ah AH=00h. AH=05h sets the date from the same registers.