!DOCTYPE html> India Time Zone Converter, Market Decision Engine, IST Clock & Business Hours Guide | WorkIndia

🇮🇳 India Time Zone Converter, IST Clock & Business Hours Tools

Check live India time, convert IST with UTC/EST/PST/GMT, and plan calls, meetings, market hours, and holidays in one place.

⏳ Loading...
India Standard Time — UTC+5:30 — No DST ever
--:--:--
🕑 What time will it be in India?
It’s in
🕓 Show live UTC / EST / PST / CET / JST clocks & copy

UTC: --

Local: --

IST 🇮🇳: --

EST: --

PST: --

CET: --

JST: --

💻 Developer tools: Local ↔ UTC text converters

Local Time to UTC Converter

Enter your local time to convert it to UTC. Accepts formats like 2026-02-26 17:30:00, 17:30, or Feb 26, 2026 5:30 PM.

UTC to Local Time Converter

Enter a UTC time to see it in your local timezone. Accepts the same flexible formats.

UTC to IST Conversion Cheat Sheet

IST = UTC + 5:30. Quick reference for all 24 hours — click any row to copy the IST time.

UTC Time IST Time 🇮🇳 EST (US East) PST (US West) GMT (London)

💡 Tip: Click any IST cell to copy that time. EST = UTC-5, PST = UTC-8, IST = UTC+5:30.

Common Timezone Conversions to IST

Instantly see what time it is in India for popular US, UK and EU times. Used by remote teams, recruiters, and travelers.

EST → IST (add 10h 30m)
9:00 AM EST = 7:30 PM IST
12:00 PM EST = 10:30 PM IST
5:00 PM EST = 3:30 AM IST (+1d)
8:00 PM EST = 6:30 AM IST (+1d)
PST → IST (add 13h 30m)
9:00 AM PST = 10:30 PM IST
12:00 PM PST = 1:30 AM IST (+1d)
5:00 PM PST = 6:30 AM IST (+1d)
8:00 PM PST = 9:30 AM IST (+1d)
GMT → IST (add 5h 30m)
9:00 AM GMT = 2:30 PM IST
12:00 PM GMT = 5:30 PM IST
5:00 PM GMT = 10:30 PM IST
8:00 PM GMT = 1:30 AM IST (+1d)
CET → IST (add 4h 30m)
9:00 AM CET = 1:30 PM IST
12:00 PM CET = 4:30 PM IST
5:00 PM CET = 9:30 PM IST
8:00 PM CET = 12:30 AM IST (+1d)

* All times are in 24-hour format with milliseconds.

🔍 Popular Time Conversion Answers

Quick answers to the most searched India time questions. All conversions are fixed offsets — India never observes DST.

🇺🇸 EST → IST (add 10h 30m)
6 AM EST= 4:30 PM IST
8 AM EST= 6:30 PM IST
9 AM EST= 7:30 PM IST
10 AM EST= 8:30 PM IST
12 PM EST= 10:30 PM IST
3 PM EST= 1:30 AM IST +1d
5 PM EST= 3:30 AM IST +1d
6 PM EST= 4:30 AM IST +1d
🇺🇸 PST → IST (add 13h 30m)
6 AM PST= 7:30 PM IST
8 AM PST= 9:30 PM IST
9 AM PST= 10:30 PM IST
10 AM PST= 11:30 PM IST
12 PM PST= 1:30 AM IST +1d
3 PM PST= 4:30 AM IST +1d
5 PM PST= 6:30 AM IST +1d
6 PM PST= 7:30 AM IST +1d
🇬🇧 GMT/BST → IST (add 5h 30m / 4h 30m)
8 AM GMT= 1:30 PM IST
9 AM GMT= 2:30 PM IST
10 AM GMT= 3:30 PM IST
12 PM GMT= 5:30 PM IST
3 PM GMT= 8:30 PM IST
5 PM GMT= 10:30 PM IST
8 PM GMT= 1:30 AM IST +1d
9 AM BST= 1:30 PM IST
🇦🇪 Dubai / CET → IST
9 AM GST (Dubai)= 10:30 AM IST
12 PM GST (Dubai)= 1:30 PM IST
5 PM GST (Dubai)= 6:30 PM IST
9 AM CET (Berlin)= 1:30 PM IST
12 PM CET (Berlin)= 4:30 PM IST
5 PM CET (Berlin)= 9:30 PM IST
9 AM SGT (Singapore)= 6:30 AM IST
9 AM AEST (Sydney)= 3:30 AM IST

💡 EST = US East Coast winter • EDT = US East Coast summer (same as EST+1h) • PST = US West Coast winter • PDT = US West Coast summer • India IST never changes.

🌎 How Far Ahead is India Right Now?

India does not observe Daylight Saving Time — IST is always UTC+5:30, a fixed offset year-round.

💡 Tip: India is ahead of the US and Europe but behind Japan, Singapore & Australia. The +5:30 half-hour offset is unique to India, Sri Lanka, and Nepal region.

📚 Developer Guides: UTC, IST, DST and Timezone Reference

⏰
DST Bugs & Fixes
Hardcoded offsets, cron skip/double-fire, ambiguous DB timestamps – and how to fix all of them.
JavaScript • SQL • Node-cron →
📌
8 Datetime Gotchas
2 AM that doesn't exist, off-by-one-day in IST, moment.js deprecation, ISO strings without Z, and more.
All languages →
💻
Java, Python & Go Pitfalls
Legacy java.util.Date, Python naive/aware trap, Django USE_TZ, Go reference time format, ParseInLocation.
Copy-paste fixes →
📋
UTC & IST Code Snippets
Ready-to-copy UTC→IST conversion code in JavaScript, Python, Java, and SQL.
JS • Python • Java • SQL →
🌎
Why IST is UTC+5:30
Why India uses a half-hour offset, the 82.5°E meridian story, and why IST never has DST.
Read the history →
📅
India Working Hours Overlap
Overlap windows between India and US East, US West, UK, EU, Singapore & Australia for scheduling meetings.
View overlap table →

Time Zone Converter (IST, UTC, EST, PST, GMT)

Pick any two cities and a time — instantly see the converted result. Perfect for scheduling international meetings.

World Clock: Current Time in India and Major Cities

Live current time in major cities around the world, updated every second.

Unix Epoch Timestamp Converter (Epoch to Date and Date to Epoch)

Convert between Unix epoch (seconds or milliseconds) and human-readable date/time — essential for developers debugging logs and APIs.

Epoch to Date Converter

Current epoch: –

Date to Epoch Converter

Meeting Planner Across Time Zones (Find the Best Overlap)

Pick a date to see all 24 UTC hours across 9 cities. Green rows = all overlap in working hours. Blue highlight = current hour right now.

Working hours overlap Current hour (today) Outside working hours

📅 Date Calculator: Age, Business Days and Countdown

Age, days between dates, business days, countdown & leap year – all calculated instantly for today.

🎂 Age Calculator
📏 Days Between Two Dates
💼 Business Days Calculator
⏳ Countdown to a Date
⏱ Exact Duration Between Two Date+Times
🌿 Leap Year Checker

🏷 Time Zone Abbreviation Decoder (IST, EST, PST, GMT)

Paste any timezone abbreviation – IST, CST, EST, PST, BST etc ? and instantly see every possible meaning with live current times.

Results appear as you type
⚠ Why this matters
IST = India Standard Time or Israel Standard Time or Irish Standard Time
CST = US Central Time or China Standard Time or Cuba Standard Time
BST = British Summer Time or Bangladesh Standard Time
Always confirm which region is meant before scheduling!

⚙ Cron Expression to IST Converter and Preview

Enter a cron expression (UTC-based) and see the next 8 fire times in UTC, IST, and your local time – side by side. Essential for debugging cron jobs running on Indian servers.

Quick fill:

Format: minute hour day-of-month month day-of-week • Assumes UTC timezone as most production cron jobs run in UTC.

📋 Timestamp Parser (ISO 8601, RFC 2822, Unix Epoch)

Paste any timestamp string from an API log, email header, or calendar file – instantly decoded across all timezones.

Examples:

📞 Best Time to Call India Right Now (Live IST)

Pick your city – see instantly if India business hours (9 AM–6 PM IST) overlap with your current time right now, and find the best window today.

Updates live every minute

Best Time to Call India Across Time Zones

If you are calling India for work, sales, support, or client meetings, the best approach is to target normal Indian business hours: 9:00 AM to 6:00 PM IST (Monday to Friday). Most teams see the highest response rates between 10:00 AM and 1:00 PM IST and again from 2:30 PM to 5:30 PM IST. Calls outside these windows are more likely to be missed or delayed, especially for decision makers in finance, logistics, and operations.

Use the overlap windows below as a practical baseline, then adjust for Daylight Saving Time in the USA, UK, and Australia. If you are scheduling a first-time business call, aim for the earlier half of India’s day when teams are less likely to be in internal meetings. For urgent conversations, choose overlap windows where both countries are in active office hours, not just awake hours.

Planning a meeting across different timezones? Use our Meeting Planner to find practical overlap slots by city and timezone.

Quick calling rule (timezone-neutral)

Target India business hours (9:00 AM - 6:00 PM IST), then prioritize the overlap where both sides are within normal office hours. The live overlap chart above already reflects this based on your selected city.

This guide works best when used with the live tool above, since the current IST time and city-specific offset can change your exact calling window across seasons.

Related Tools

🔁 DST Transition Countdown for India Time Difference

India never observes DST – but the US, UK and EU do. When their clocks change, your IST meeting time shifts. See exactly when, and by how much.

🕐 Check how a recurring meeting shifts

UTC to IST & Timezone Converter is a free tool to convert between UTC, IST, GMT, EST, PST, CET, JST and other timezones instantly. Built for developers, remote workers, travelers, and business professionals worldwide.

Maintained by Harshit Yadav. All calculations run entirely in your browser — no data is ever sent to a server.

This site does not collect, store, or share any personal information. No user tracking is performed by this site. Google AdSense may use cookies to serve relevant ads — see Google's Ad Policy.

No registration or login is required. Any data you enter is processed only in your browser.

This tool is provided for informational purposes only. While we strive for accuracy, we do not guarantee the correctness of any conversion. Always verify critical times for business or travel. Use at your own risk.

Have feedback or suggestions?

How do I convert UTC to IST?

Add 5 hours and 30 minutes. So 12:00 UTC = 17:30 IST. Use the Quick Convert bar on the Home tab for instant results.

What is the difference between UTC and GMT?

GMT is a time zone; UTC is a time standard. They show the same time value, but UTC is more precise and is the global standard used in computing and communications.

Why should developers store timestamps in UTC?

UTC avoids ambiguity from daylight saving time changes and regional offsets. Databases and APIs that store UTC timestamps work correctly for users in any timezone.

Does this tool work offline?

Yes — once the page is loaded, all timezone calculations run locally in your browser with no internet connection required.

What is a Unix epoch timestamp?

A Unix timestamp is the number of seconds (or milliseconds) since January 1, 1970 00:00:00 UTC. Use the Epoch tab to convert between timestamps and readable dates.

Best Practices

  • Always store in UTC — convert to local time only for display.
  • Use ISO 8601 format — YYYY-MM-DDTHH:mm:ss.sssZ ensures universal compatibility.
  • Handle DST transitions — use IANA timezone names (e.g. America/New_York) not fixed offsets.
  • Test across timezones — run your app with different system timezone settings.

Common Mistakes

  • Mixing local and UTC times — causes data inconsistencies.
  • Assuming fixed UTC offsets — regions change offsets seasonally.
  • Ignoring DST transitions — off-by-one-hour bugs appear twice a year.

DST causes more production incidents than almost any other datetime issue. Here are the bugs developers hit every year and how to fix them.

2026 DST dates to mark in your calendar: US clocks spring forward March 8 (EST?EDT, UTC-5?UTC-4) and fall back Nov 1. EU springs forward March 29 (CET?CEST, UTC+1?UTC+2) and falls back Oct 25. India (IST) never observes DST.

Bug #1 – Hardcoded UTC offset breaks twice a year

JavaScript – WRONG (breaks every DST change) 
// BAD ? hardcoded offset. Wrong for 6 months of the year.
const estOffset = -5 * 60; // assumes EST, but NYC is EDT (UTC-4) in summer
const estTime = new Date(Date.now() + estOffset * 60000);
JavaScript – CORRECT (DST-safe) 
// GOOD ? let the IANA database handle the offset
const estTime = new Date().toLocaleString('en-US', { timeZone: 'America/New_York' });
// Works correctly year-round ? EST in winter, EDT in summer

Bug #2 – JavaScript date string parsing (UTC vs local)

JavaScript – The silent 1-character trap 
// Date-only string ? parsed as UTC midnight
new Date('2026-03-08').toISOString()
// ? "2026-03-08T00:00:00.000Z"  ? UTC midnight
// ? In IST: Mar 8 05:30 AM ? in EST: Mar 7 7:00 PM ? WRONG DAY!

// Datetime string without Z ? parsed as LOCAL time
new Date('2026-03-08T00:00:00').toISOString()
// ? Depends on the machine's timezone ? unpredictable in Node.js

// FIX ? always append Z for UTC, or use explicit offset
new Date('2026-03-08T00:00:00Z')    // explicit UTC ?
new Date('2026-03-08T00:00:00+05:30') // explicit IST ?

Bug #3 – Cron jobs that run twice or skip on DST day

Cron / Node.js scheduler 
# BAD ? "0 2 * * *" in a US/Eastern cron will:
#   ? skip entirely on Mar 8 (clocks jump 1:59–3:00, so 2 AM never exists)
#   ? run TWICE on Nov 1  (clocks fall back 2:59–2:00, so 2 AM repeats)

# FIX ? schedule cron in UTC, then convert for display only
# "0 2 * * *" UTC = 7:30 AM IST year-round (IST never changes)
# "0 7 * * *" UTC = 2:00 AM EST / 3:00 AM EDT (off by 1h in summer)

// Node.js ? node-cron with UTC timezone
const cron = require('node-cron');
cron.schedule('0 2 * * *', () => { /* task */ }, { timezone: 'UTC' });
// UTC-scheduled jobs are immune to DST

Bug #4 – Database stores local time, DST makes it ambiguous

SQL – storing local vs UTC 
-- BAD: DATETIME in MySQL stores no timezone info
-- "2026-11-01 01:30:00" is ambiguous ? happened before OR after clock fallback?
CREATE TABLE orders (created_at DATETIME); -- ambiguous during DST

-- GOOD: store UTC, convert at query time
CREATE TABLE orders (created_at TIMESTAMP); -- MySQL TIMESTAMP stores UTC internally
-- or store as BIGINT (Unix epoch ms) ? unambiguous, timezone-free
CREATE TABLE orders (created_at_ms BIGINT);

-- PostgreSQL: use TIMESTAMPTZ (timestamp with time zone) ? always UTC internally
CREATE TABLE orders (created_at TIMESTAMPTZ DEFAULT NOW()); -- recommended ?
Countries that do NOT observe DST (safe for fixed-offset use): India (IST +5:30), China (CST +8), Japan (JST +9), Singapore (SGT +8), UAE (GST +4), most of Africa, and most of Southeast Asia. The US, EU, Canada, Australia, and most of South America do observe DST.

These are the datetime edge cases that cause subtle bugs even for experienced developers.

Gotcha What happens Fix
2 AM doesn't exist On DST spring-forward day (e.g. Mar 8 US), clocks jump 1:59–3:00. Any logic targeting 2 AM silently skips. Schedule in UTC or check if the resulting time is valid after conversion.
2 AM happens twice On DST fall-back day (e.g. Nov 1 US), clocks roll back 2:59–2:00. Tasks fire twice; records appear out of order. Store timestamps as UTC epoch (Unix ms). Order by epoch, not by display time.
Off-by-one-day in IST new Date('2026-03-08') is Mar 8 00:00 UTC = Mar 7 at 11:30 PM IST. Displaying this date in IST shows the wrong day. Use new Date('2026-03-08T00:00:00+05:30') to anchor the date in IST, or always pass dates as YYYY-MM-DDT00:00:00Z and convert.
Leap seconds UTC occasionally adds a 23:59:60 second. Most languages ignore this, but POSIX time smears it, causing subtle 1-second drift in high-precision systems. Use NTP-synced servers. For financial/audit systems, use TAI or explicitly document your handling.
moment.js is legacy Moment.js is in maintenance mode. Mutable date objects and large bundle size are known issues. Use Temporal API (stage 3), date-fns, or Luxon for new projects.
ISO string without Z "2026-03-08T12:00:00" ? no timezone indicator. Chrome, Node, and Safari may parse it differently (local vs UTC). Always include offset: "2026-03-08T12:00:00Z" or "?+05:30". Never pass naked ISO strings between systems.
toLocaleDateString() varies by browser Output format differs across browsers and OS locales. Can't be reliably parsed back to a Date. Use Intl.DateTimeFormat with explicit locale and timeZone options for consistent display.
Log timestamps out of order Distributed servers in different timezones log events with local time. Merging logs makes events appear to go backwards. Always log in UTC ISO 8601 (2026-03-08T12:00:00.000Z). Tools like Loki, Splunk, and Datadog sort by UTC by default.
Golden rule for India-based developers: IST is UTC+5:30 with no DST, ever. Your backend UTC timestamps are always IST = UTC + 5h 30m ? a single, fixed arithmetic operation. This simplicity is a genuine advantage compared to working with US or EU timezones.
☕ Java ? Common Datetime Pitfalls

Pain: Java had broken datetime APIs (java.util.Date, Calendar) for 20 years. Java 8 introduced java.time (JSR-310) ? but legacy code and bad habits persist.

Bug #1 – Using Date and Calendar (legacy API)

Java – WRONG (pre-Java 8 style) 
// BAD ? java.util.Date is mutable, month is 0-indexed, no timezone
Date date = new Date(2026, 2, 8); // !! month=2 means MARCH, not February
Calendar cal = Calendar.getInstance();    // uses JVM default timezone ? varies per server
cal.set(Calendar.HOUR_OF_DAY, 0);        // silently uses local time, not UTC
Java – CORRECT (java.time, Java 8+) 
// GOOD ? immutable, explicit, timezone-aware
import java.time.*;

LocalDate date = LocalDate.of(2026, 3, 8);  // month is 1-indexed ?
ZonedDateTime istNow = ZonedDateTime.now(ZoneId.of("Asia/Kolkata"));
ZonedDateTime utcNow = ZonedDateTime.now(ZoneOffset.UTC);

// Convert UTC to IST
Instant instant = Instant.parse("2026-03-08T12:00:00Z");
ZonedDateTime ist = instant.atZone(ZoneId.of("Asia/Kolkata"));
// ? 2026-03-08T17:30:00+05:30[Asia/Kolkata]

Bug #2 – JVM default timezone changes between environments

Java – Pin JVM timezone at startup 
// Works on dev machine (IST), fails on UTC AWS server ? fix at app startup
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));

// OR pass as JVM arg (preferred for Spring Boot / containers)
// java -Duser.timezone=UTC -jar app.jar

// Spring Boot application.properties
// spring.jpa.properties.hibernate.jdbc.time_zone=UTC

Bug #3 – Hibernate / JPA losing timezone on persist

Java / Spring Boot – Hibernate timezone config 
// BAD ? entity field without explicit timezone handling
@Column
private LocalDateTime createdAt; // no timezone! Hibernate uses JVM default

// GOOD ? use Instant or ZonedDateTime, configure Hibernate to write UTC
@Column(columnDefinition = "TIMESTAMP WITH TIME ZONE")
private Instant createdAt = Instant.now(); // always UTC ?

// application.properties
// spring.jpa.properties.hibernate.jdbc.time_zone=UTC
🐍 Python – Common Datetime Pitfalls

Pain: Python's datetime module distinguishes naive (no timezone) vs aware (has timezone) objects. Mixing them raises TypeError ? or worse, silently produces wrong results.

Bug #1 – Naive vs aware datetime mixing

Python – The naive/aware trap 
# BAD ? datetime.now() returns NAIVE datetime (no timezone info)
from datetime import datetime
naive = datetime.now()          # naive ? no tzinfo, assumes local system time
utc   = datetime.utcnow()       # ALSO naive! Despite the name, no tzinfo attached

# This raises TypeError: can't compare offset-naive and offset-aware datetimes
import pytz
aware = datetime.now(pytz.utc)
diff  = aware - naive           # ? TypeError

# GOOD ? always use timezone-aware datetimes from the start
from datetime import datetime, timezone
utc_now = datetime.now(timezone.utc)   # aware UTC ? (no extra package)

from zoneinfo import ZoneInfo          # Python 3.9+
ist_now = datetime.now(ZoneInfo('Asia/Kolkata'))  # aware IST ?

Bug #2 – datetime.utcnow() is deprecated and misleading

Python – Replace utcnow() correctly 
# datetime.utcnow() deprecated in Python 3.12 ? returns naive UTC (confusing)
# Use datetime.now(timezone.utc) instead

from datetime import datetime, timezone

# OLD (deprecated)
ts = datetime.utcnow()                          # naive, misleading ?

# NEW (correct)
ts = datetime.now(timezone.utc)                 # aware UTC ?
ts_iso = ts.isoformat()                         # "2026-03-08T12:00:00+00:00"
ts_ist = ts.astimezone(ZoneInfo('Asia/Kolkata')) # convert to IST ?

Bug #3 – pytz.localize() vs replace() ? wrong way to attach timezone

Python / pytz – localize vs replace 
import pytz
from datetime import datetime
ist = pytz.timezone('Asia/Kolkata')

naive_dt = datetime(2026, 3, 8, 12, 0, 0)

# BAD ? replace() does not account for historical DST data in pytz
wrong = naive_dt.replace(tzinfo=ist)   # ? may use LMT offset (+5:21) not +5:30

# GOOD ? use localize() with pytz
correct = ist.localize(naive_dt)       # ? uses correct IST +05:30
print(correct)  # 2026-03-08 12:00:00+05:30

# Or avoid pytz entirely ? use zoneinfo (Python 3.9+)
from zoneinfo import ZoneInfo
correct2 = naive_dt.replace(tzinfo=ZoneInfo('Asia/Kolkata'))  # ? safe with zoneinfo

Bug #4 – Django / Flask storing naive datetimes in DB

Django – USE_TZ setting 
# settings.py ? USE_TZ=False (default in older Django) stores naive local time
USE_TZ = False  # ? ? all auto_now / auto_now_add fields store server local time

# GOOD ? always enable USE_TZ
USE_TZ   = True           # ? stores UTC in DB, converts to TIME_ZONE for display
TIME_ZONE = 'Asia/Kolkata'  # display timezone (not storage timezone)

# In views/serializers ? use django.utils.timezone, NOT datetime.now()
from django.utils import timezone
now = timezone.now()   # aware UTC datetime ?
# datetime.now() would give naive local time ?
🦉 Go (Golang) ? Common Datetime Pitfalls

Pain: Go's time package is powerful but has sharp edges ? time.Now() uses the local system timezone, time.Parse silently defaults to UTC, and the reference time format (Mon Jan 2 15:04:05 2006) trips up every new Go developer.

Bug #1 – The reference time format (Go's biggest WTF)

Go – Format reference time explained 
// BAD ? using YYYY-MM-DD style (works in every other language, fails in Go)
t.Format("YYYY-MM-DD HH:mm:ss")  // ? outputs literal "YYYY-MM-DD HH:mm:ss"

// Go uses a SPECIFIC reference time: Mon Jan 2 15:04:05 MST 2006
// Each component must match that exact reference value:
//   Year=2006  Month=01(Jan)  Day=02  Hour=15  Min=04  Sec=05  TZ=MST/-07:00

// CORRECT formats
t.Format("2006-01-02 15:04:05")          // ? YYYY-MM-DD HH:MM:SS
t.Format(time.RFC3339)                   // ? "2026-03-08T12:00:00+05:30"
t.Format("2006-01-02T15:04:05Z07:00")  // ? ISO 8601 with timezone

Bug #2 – time.Parse ignores timezone, time.ParseInLocation is the fix

Go – Parsing with correct location 
import "time"

// BAD ? time.Parse with no zone in format string ? result is UTC
t, _ := time.Parse("2006-01-02 15:04:05", "2026-03-08 12:00:00")
// t.Location() == UTC ? even if you meant IST ?

// GOOD ? use ParseInLocation to specify the timezone
ist, _ := time.LoadLocation("Asia/Kolkata")
t, _   := time.ParseInLocation("2006-01-02 15:04:05", "2026-03-08 12:00:00", ist)
// t is now 2026-03-08 12:00:00 +0530 IST ?

// Convert to UTC for storage
utcTime := t.UTC()
// ? 2026-03-08 06:30:00 +0000 UTC

Bug #3 – time.Now() uses local timezone, servers in UTC produce different output than dev machines

Go – Always use UTC explicitly 
// time.Now() ? uses the local system timezone (IST on your laptop, UTC on AWS)
now := time.Now()                 // varies by machine ?
nowUTC := time.Now().UTC()        // always UTC ? ? use for storage/logging

// Convert UTC to IST for display
ist, _ := time.LoadLocation("Asia/Kolkata")
istTime := time.Now().UTC().In(ist)
fmt.Println(istTime.Format(time.RFC3339))
// ? "2026-03-08T17:30:00+05:30"

// Tip: pin your Docker/server timezone to UTC to avoid surprises
// ENV TZ=UTC in Dockerfile, or set TZ=UTC in your deployment environment

Bug #4 – Comparing time.Time values across different locations

Go – Equal() vs == for time comparison 
// BAD ? == compares wall clock AND location, so UTC and IST times for the
// same instant are NOT equal with ==
utcT := time.Date(2026, 3, 8, 6, 30, 0, 0, time.UTC)
ist, _ := time.LoadLocation("Asia/Kolkata")
istT  := time.Date(2026, 3, 8, 12, 0, 0, 0, ist)
fmt.Println(utcT == istT)         // false ? (same instant, different location)

// GOOD ? use .Equal() which compares the underlying instant
fmt.Println(utcT.Equal(istT))     // true ?
// Or compare .Unix() or .UnixMilli() values directly
fmt.Println(utcT.Unix() == istT.Unix()) // true ?

Global Operations

  • Schedule calls and meetings across multiple time zones.
  • Set clear international project deadlines.
  • Time marketing emails and social posts for optimal engagement.
  • Plan webinars and conferences for global audiences.

Finance & Technology

  • Track global stock market opening and closing times.
  • Schedule server maintenance during low-traffic windows.
  • Correlate events in distributed system logs across regions.
  • Coordinate data backups across multiple data centers.

Copy-paste ready code to get IST / convert UTC in popular languages.

JavaScript 
// Get current IST time
const istTime = new Date().toLocaleString('en-IN', { timeZone: 'Asia/Kolkata' });
console.log(istTime);

// Convert a UTC Date object to IST string
function utcToIST(utcDate) {
  return utcDate.toLocaleString('en-IN', { timeZone: 'Asia/Kolkata' });
}

// Using Intl.DateTimeFormat (recommended for production)
const fmt = new Intl.DateTimeFormat('en-CA', {
  timeZone: 'Asia/Kolkata',
  year: 'numeric', month: '2-digit', day: '2-digit',
  hour: '2-digit', minute: '2-digit', second: '2-digit', hour12: false
});
console.log(fmt.format(new Date())); // e.g. 2026-02-26 17:30:00
Python 
# Using pytz (install: pip install pytz)
from datetime import datetime, timezone
import pytz

ist = pytz.timezone('Asia/Kolkata')

# Current IST time
now_ist = datetime.now(ist)
print(now_ist.strftime('%Y-%m-%d %H:%M:%S %Z'))

# Convert a UTC datetime to IST
utc_dt = datetime(2026, 2, 26, 12, 0, 0, tzinfo=timezone.utc)
ist_dt = utc_dt.astimezone(ist)
print(ist_dt.strftime('%Y-%m-%d %H:%M:%S %Z'))  # 2026-02-26 17:30:00 IST

# Python 3.9+ ? no extra package needed
from zoneinfo import ZoneInfo
now_ist = datetime.now(ZoneInfo('Asia/Kolkata'))
print(now_ist)
Java 
// Java 8+ ? java.time package
import java.time.*;
import java.time.format.*;

// Get current IST time
ZonedDateTime istNow = ZonedDateTime.now(ZoneId.of("Asia/Kolkata"));
System.out.println(istNow);

// Convert UTC instant to IST
Instant utcInstant = Instant.parse("2026-02-26T12:00:00Z");
ZonedDateTime istTime = utcInstant.atZone(ZoneId.of("Asia/Kolkata"));
System.out.println(istTime); // 2026-02-26T17:30:00+05:30[Asia/Kolkata]

// Format nicely
DateTimeFormatter fmt = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss z");
System.out.println(istTime.format(fmt)); // 2026-02-26 17:30:00 IST
SQL (MySQL) 
-- Convert stored UTC datetime column to IST
SELECT
  order_id,
  created_at AS utc_time,
  CONVERT_TZ(created_at, 'UTC', 'Asia/Kolkata') AS ist_time
FROM orders;

-- Get current time in IST
SELECT CONVERT_TZ(UTC_TIMESTAMP(), 'UTC', 'Asia/Kolkata') AS ist_now;

-- PostgreSQL equivalent (AT TIME ZONE)
SELECT NOW() AT TIME ZONE 'UTC' AT TIME ZONE 'Asia/Kolkata' AS ist_now;

India's Unique 30-Minute Offset

India Standard Time (IST) is UTC+5:30 – a half-hour offset that surprises many developers used to whole-hour timezones. Here's why:

  • Geography: India spans from ~68°E to ~97°E longitude ? roughly 29° wide. The geographic center is around 82.5°E, which corresponds exactly to UTC+5:30 (82.5? ? 15? per hour = 5.5 hours).
  • One timezone for the whole country: India chose a single nationwide timezone in 1947 for national unity and administrative simplicity, despite its geographic width.
  • The 82.5°E meridian: The Indian government selected 82°30'E longitude (passing through Mirzapur, Uttar Pradesh) as the "Indian Standard Meridian."
  • No Daylight Saving Time: India has never observed DST. This makes IST one of the most stable timezones for developers – the UTC offset never changes.
  • Half-hour offsets are rare: Only a handful of countries use them: India (+5:30), Sri Lanka (+5:30), Afghanistan (+4:30), Iran (+3:30), and Myanmar (+6:30).
Developer note: Because IST never changes, you can safely use the fixed offset +05:30 in timestamps. However, best practice is still to use the IANA timezone name Asia/Kolkata for forward compatibility.

Typical business hours are 9:00 AM ? 6:00 PM local time. The table below shows the daily overlap window with India (IST).

Region Their Business Hours (local) Same in IST Overlap Window (IST)
🇺🇸 US East (EST/EDT) 9 AM – 6 PM EST 7:30 PM – 4:30 AM IST 7:30 PM – 11:30 PM IST
🇺🇸 US West (PST/PDT) 9 AM – 6 PM PST 10:30 PM – 7:30 AM IST 10:30 PM – 12:30 AM IST
🇬🇧 UK (GMT/BST) 9 AM – 6 PM GMT 2:30 PM – 11:30 PM IST 2:30 PM – 6:00 PM IST
🇪🇺 Central Europe (CET/CEST) 9 AM – 6 PM CET 1:30 PM – 10:30 PM IST 1:30 PM – 6:00 PM IST
🇸🇬 Singapore / Malaysia (SGT) 9 AM – 6 PM SGT 6:30 AM – 3:30 PM IST 9:00 AM – 3:30 PM IST
🇦🇺 Australia East (AEST) 9 AM – 6 PM AEST 3:30 AM – 12:30 PM IST 9:00 AM – 12:30 PM IST

* EST = UTC-5, PST = UTC-8, GMT = UTC+0, CET = UTC+1, SGT = UTC+8, AEST = UTC+10. Standard (non-DST) offsets used. Overlap assumes IST business hours 9 AM–6 PM.

Advertisement