Unix Timestamps ஐக் கொண்டு Scheduled Tasks மற்றும் Cron Jobs

Cron jobs ஆனது மேலாப பார்க்கலாம் எளிமையாக இருக்கும்: இந்த command ஐ இந்த நேரத்தில் இயக்கு. ஆனால் production scheduling சீக்கிரம் சிக்கலாகிவிடும். Job எப்போது கடைசியாக இயங்கியது என்பது track செய்ய வேண்டும், அது தாமதமாகியதா என்பது கண்டறிய வேண்டும், overlapping runs ஐ handle செய்ய வேண்டும், மற்றும் failures ஐ debug செய்ய போதுமான precision உடன் log செய்ய வேண்டும். Unix timestamps என்பது இதனுடைய practical tool.

Unix Timestamp Converter ஐ பயன்படுத்தி எந்த timestamp ஐயும் human-readable date ஆக convert செய்யலாம் அல்லது current Unix time ஐ பெறலாம். இந்த article ஆனது timestamps ஐ scheduling systems ல் எப்படி பயன்படுத்தப்படுகிறது என்பதை cover செய்கிறது — basic cron இலிருந்து more complex job queues வரை.

ஏன் Scheduled Tasks ஆனது Unix Timestamps ஐ பயன்படுத்துகிறது

0 2 * போன்ற cron expression ஆனது scheduler க்கு job ஐ எப்போது இயக்க வேண்டும் என்பது சொல்கிறது. ஆனால் run ஆகும் போது என்ன நிகழ்ந்தது என்பற்றி இது சொல்லாது. அதற்கு நீங்கள் runtime ல் timestamps ஐ record செய்ய வேண்டும்: job எப்போது start ஆனது, எப்போது end ஆனது, அது succeed ஆனதா.

Unix timestamps ஆனது இதற்கான natural format ஆகும், ஏனெனில் அவை:

Unambiguous — timezone confusion இல்லை, locale-dependent formatting இல்லை
Comparable — two timestamps ஐ subtract செய்து elapsed seconds ஐ பெறலாம்
Compact — single integer ஆனது எந்த database column அல்லது log line ல் store ஆகும்
Sortable — integer ordering ஆனது chronological ordering க்கு சமம்

started_at: 1712534400 ஐ database ல் write செய்யும் scheduled task ஆனது precise மற்றும் queryable ஐ record செய்கிறது. started_at: "April 8, 2026 at 2:00 AM" ஐ write செய்யும் task ஆனது useful ஆகுவதற்கு முன் parsing ஆவி தேவைப்படும் ஒன்றை record செய்கிறது.

Last-Run Timestamps ஐ Store செய்தல்

Scheduled tasks ல் timestamps ஆனது last successful run ஐ track செய்வது common use case ஆகும். ஒரு simple pattern:

1. Job start ஆகும், last_run timestamp ஐ storage இலிருந்து read செய்கிறது 2. Job அதன் work ஐ செய்கிறது 3. Success ஆனால், current Unix timestamp ஐ last_run ல் write செய்கிறது 4. Failure ஆனால், last_run ஐ unchanged விடுகிறது (அல்லது separate last_failed_at field க்கு write செய்கிறது)

# Shell example
LAST_RUN=$(cat /var/run/myjob.timestamp 2>/dev/null || echo 0)
NOW=$(date +%s)

# Do work here...
if [ $? -eq 0 ]; then
    echo $NOW > /var/run/myjob.timestamp
fi

இந்த pattern "இந்த job எப்போது கடைசியாக succeed ஆனது?" என்ற கேள்விக்கு trivial ஆக answer கொடுக்கிறது — file ஐ read செய்து timestamp ஐ convert செய்யுங்கள். இது staleness ஐ detect செய்வதும் easy செய்கிறது: now - last_run > expected_interval ஆனால், job overdue ஆகும்.

Overdue அல்லது Missed Jobs ஐ Detect செய்தல்

Cron ஆனது அதன் own failures ஐ detect செய்யாது. Server ஆனது scheduled run ஆகும் போது down ஆனால், cron retry செய்யாது மற்றும் alert செய்யாது. Job run ஆனால் error உடன் exit ஆனால், cron அதை failed ஆக mark செய்யாது. இந்த situations ஐ detect செய்வதற்கு timestamps ஐ check செய்யும் external monitoring ஆவசியம்.

Simple overdue check: current time minus last_run ஆனது threshold ஐ exceed செய்தால், something wrong ஆனது.

import time

EXPECTED_INTERVAL_SECONDS = 3600  # job should run hourly
TOLERANCE_SECONDS = 300           # allow 5 minutes of drift

last_run = get_last_run_timestamp()  # from DB or file
now = int(time.time())

if now - last_run > EXPECTED_INTERVAL_SECONDS + TOLERANCE_SECONDS:
    alert("Job overdue — last ran at {}".format(last_run))

Tolerance matter செய்கிறது. Cron jobs ஆனது always exactly schedule ல் start ஆகாது — system load, clock drift, மற்றும் startup time mean 02:00:00 ற்கு scheduled job ஆனது actually 02:00:04 ல் start ஆகலாம். Tolerance இல்லாமல், 02:59:56 ல் run ஆகும் monitoring check ஆனது job ஐ overdue ஆக see செய்யலாம் அது 02:00:04 ல் fine ஆக run ஆனது மற்றும் 4 seconds ல் due ஆகும் எனினும்.

Hourly jobs க்கு, 5 minutes ஒரு reasonable tolerance ஆகும். Daily jobs க்கு, 30–60 minutes typical ஆகும்.

Overlapping Runs ஐ Timestamps உடன் Prevent செய்தல்

Long-running jobs ஆனது overlap ஆக செய்யலாம் next scheduled run current ஆனது முடிவுக்கு வரும் முன் start ஆனால். Daily backup job ஆனது 2 hours take செய்யுது fine ஆகும். 26 hours take செய்யுது overlapping start ஆகும் மற்றும் eventually cascading failures cause செய்கிறது.

Timestamps ஆனது simple lock pattern உடன் solve செய்கிறது:

1. Job start ஆகும், lock record இலிருந்து started_at ஐ read செய்கிறது 2. started_at exist செய்து now - started_at < timeout ஆனால், another run in progress ஆகும் — exit செய்யுங்கள் 3. Lock இல்லாமல் அல்லது lock expired ஆனால், current timestamp ஐ started_at ஆக write செய்யுங்கள் 4. Work செய்யுங்கள் 5. Completion ல் lock ஐ clear செய்யுங்கள்

LOCK_TIMEOUT = 7200  # 2 hours — if job runs longer, assume it's stuck

lock_time = get_lock_timestamp()
now = int(time.time())

if lock_time and (now - lock_time) < LOCK_TIMEOUT:
    print("Job already running, started at {}".format(lock_time))
    exit(0)

set_lock_timestamp(now)
# ... do work ...
clear_lock()

Timeout ஆனது case ஐ handle செய்கிறது job crash ஆக அதன் lock clear செய்யாமல். Timeout இல்லாமல், crashed job ஆனது indefinitely all future runs ஐ block செய்யும். Timestamp-based lock உடன், crashed run ஆனது lock timeout ஐ expire செய்கிறது, மற்றும் next scheduled run proceed ஆக செய்யலாம்.

Future Jobs ஐ Timestamps உடன் Schedule செய்தல்

Job queues (Sidekiq, Celery, BullMQ, RQ) ஆனது often future tasks ஐ schedule செய்கிறது job execute ஆக வேண்டிய Unix timestamp ஐ store செய்து. Queue worker polls jobs எங்கு run_at <= current_timestamp.

-- Find jobs ready to run
SELECT * FROM scheduled_jobs
WHERE run_at <= EXTRACT(EPOCH FROM NOW())::int
  AND status = 'pending'
ORDER BY run_at ASC;

இது cron ஐ விட more flexible dynamic scheduling க்கு. "Run every hour" ஆக சொல்வதற்கு பதில், நீங்கள் "Run 24 hours after the user signs up" அல்லது "Run 15 minutes after this payment failed" சொல்லலாம். Job ஆனது run_at = NOW_UNIX + delay_seconds உடன் insert ஆகும், மற்றும் worker time வரும் போது அதை pick up செய்கிறது.

Retry logic ஆனது இந்த way ல் work செய்கிறது. Failure ஆக, exponential backoff உடன் reschedule செய்யுங்கள்:

attempt = job.attempt_count
delay = min(2 ** attempt * 60, 3600)  # 1min, 2min, 4min... up to 1hr
job.run_at = int(time.time()) + delay
job.save()

1 attempt ஆக: 60 seconds ல் retry செய்யுங்கள். 2 ஆக: 120 seconds. 3 ஆக: 240 seconds. 3600 ல் cap indefinite delays ஐ prevent செய்கிறது.

Job Runs ஐ Unix Timestamps உடன் Log செய்தல்

Job run logs ஆனது most useful precise timing include செய்யும் போது. Log line போல:

[1712534400] backup-job started
[1712534447] backup-job completed in 47s, 3.2GB written

ஆனது immediately useful debugging க்கு. நீங்கள் 1712534400 ஐ human-readable date ஆக convert செய்யலாம் Unix Timestamp Converter ஐ பயன்படுத்தி, அதை other system logs உடன் correlate செய்யலாம், மற்றும் exact duration ஐ calculate செய்யலாம் date strings ஐ parse செய்யாமல்.

Alternative — "2026-04-08 02:00:00 UTC" போல formatted strings ஐ log செய்வது — human க்கு readable ஆனால் machines க்கு fragile ஆகும். Different log shippers dates ஐ differently format செய்கிறது, timezone conversions errors introduce செய்கிறது, மற்றும் string comparison time-range queries க்கு integer comparison ஐ விட slower ஆகும்.

Common pattern ஆனது both ஐ log செய்வது: machine readability க்கு raw timestamp மற்றும் human readability க்கு formatted date.

started_at=1712534400 started_at_human="2026-04-08T02:00:00Z" duration_s=47

Job Duration மற்றும் Performance Over Time ஐ Measure செய்தல்

Timestamps ஆனது performance tracking ஐ across runs enable செய்கிறது. started_at மற்றும் completed_at ஐ each run க்கு record செய்யுங்கள், மற்றும் நீங்கள் query செய்யலாம்:

Average duration last 30 runs ஆக
Longest run past week ல்
Duration ஆனது trending up ஆக (possible performance regression)

SELECT
    AVG(completed_at - started_at) AS avg_duration_seconds,
    MAX(completed_at - started_at) AS max_duration_seconds,
    COUNT(*) AS run_count
FROM job_runs
WHERE job_name = 'nightly-report'
  AND started_at > EXTRACT(EPOCH FROM NOW())::int - (30 * 86400);

இந்த type ஆன query ஆனது possible simple integer subtraction ஆக durations store செய்வதால். Formatted dates ஐ store செய்தால், arithmetic முன் string parsing ஆவசியம்.

Timestamp Precision: Seconds vs Milliseconds Scheduling ல்

Most scheduled tasks க்கு, second-level precision sufficient ஆகும். 1712534400 ற்கு schedule செய்யப்பட்ட job sub-second accuracy ஆவசியம் இல்லை.

ஆனால் high-frequency task queues க்கு — jobs ஆனது hundreds of times per second ஆக run ஆக செய்யலாம் — millisecond timestamps matter செய்கிறது. Two jobs ஆனது same second ல் insert ஆனால் மற்றும் timestamp ல் sort செய்து processing order ஐ determine செய்தால், second-level timestamps ties produce செய்கிறது. Millisecond timestamps insertion order ஐ preserve செய்கிறது each second ல்.

JavaScript ஆனது Date.now() milliseconds return செய்கிறது. Python ஆனது time.time() float உடன் microsecond precision ஐ return செய்கிறது. Most databases microsecond-precision timestamps ஐ support செய்கிறது. Precision ஆனது choice scheduling frequency உடன் match ஆக வேண்டும் — milliseconds high-volume queues க்கு, seconds standard cron-like jobs க்கு.

Daylight Saving Time ஐ Scheduled Tasks ல் Handle செய்தல்

இங்கே many scheduling bugs hide செய்கிறது. 0 2 * ஆக configured cron job ஆனது 2:00 AM local time ல் run ஆகும். Clocks spring forward ஆனால், 2:00 AM exist செய்யாது — clock 1:59 AM இலிருந்து 3:00 AM க்கு go செய்கிறது. Job skip ஆகும் அல்லது 3:00 AM ல் run ஆகும் cron implementation ஐ depending.

Clocks fall back ஆனால், 2:00 AM twice occur செய்கிறது. Job twice run ஆக செய்யலாம்.

Solution: cron ஐ UTC ல் run செய்யுங்கள். 0 2 * UTC ல் ஆனது always 2:00 UTC ஆகும் — ambiguity இல்லை, DST surprises இல்லை. Job time relative local time க்கு shift ஆகும் twice year, ஆனால் அது always exactly once run ஆகும்.

Unix timestamps ஆனது UTC definition ஆக, இதனால் அவை problem க்கு immune ஆகிறது. Job timestamp 1712534400 ல் run ஆக schedule செய்யப்பட்டால் exact moment ல் run ஆகும் regardless server ஆனது என்ன timezone ஆக அல்லது என்ன DST offset apply ஆக அந்த time ல். இது core argument ஆகும் timestamp-based schedulers ஐ cron க்கு use செய்வதற்கு anything exact timing matters.

Jobs local time semantics matter — "Run at 9 AM business hours" — explicit timezone handling ஆவசியம் just UTC இல்லாமல். Target timezone store செய்யுங்கள் schedule உடன் along, UTC க்கு schedule creation time ல் convert செய்யுங்கள், மற்றும் recompute timezone ஆனது DST rules change ஆனால்.