Learn how to compare prop firm platform server time with your local time, UTC and economic-calendar time so you can avoid news trading and daily reset mistakes.
Akash Mane is the Founder and CEO of Prop Firm Bridge, where he leads the company’s vision, platform growth, and long term strategic direction. He oversees operations across research, marketing, content systems, SEO, and product positioning while driving the platform’s mission of becoming a trusted authority in the prop firm industry. At Prop Firm Bridge, Akash plays a direct role in shaping educational frameworks, comparison systems, and trader focused resources designed to help users make informed decisions with transparency and confidence. His work focuses on building scalable organic growth systems, improving platform authority, and strengthening trust through accurate, structured, and search optimized content. In addition to leadership responsibilities, he actively manages growth strategy, social media marketing, search visibility, and brand development to expand the platform’s reach across global trading audiences.
Manoj Gholap is responsible for content accuracy, compliance, and factual integrity at Prop Firm Bridge. He acts as the final verification layer for all published content, ensuring that prop firm reviews, rules, and comparisons are clear, accurate, and aligned with transparency standards. Manoj plays a key role in maintaining trust and credibility across the platform.
A prop firm trader can look at a phone, an economic calendar and a trading platform at the same moment and see three different clock times. That does not automatically mean one clock is wrong. The phone shows local time. The event source may use Eastern Time, London time or another official timezone. The trading platform can use a server offset chosen by its infrastructure. Problems begin when the trader assumes those clocks are interchangeable.
Server time matters because a chart candle, order timestamp, daily reset or news restriction can be interpreted through a clock that is not the trader's local clock. A one-hour daylight-saving change can move a news filter. A half-hour error can matter for Indian traders. A platform migration can change the server offset without changing the trader's phone. The safe approach is to treat server time as a separate field that must be measured and documented.
For 2026, the seasonal details are also important. New York changes from EST to EDT on March 8 and returns to EST on November 1. The UK changes to British Summer Time on March 29 and returns to GMT on October 25. Japan Standard Time remains UTC+9 without daylight saving. India remains UTC+5:30. Those differences explain why a conversion that worked in September can become wrong later in the year.
Author credibility: This article is written by Akash Mane, Founder and CEO of Prop Firm Bridge, using data-backed prop firm rule research and current 2026 time-zone references. Manoj Gholap is the fact checker.
Table of Contents
Quick answer: To check prop firm server time, compare the live platform clock with UTC and calculate the offset. Then confirm whether that offset changes seasonally. Keep server time, local time and official event time as separate labeled clocks. For news events, convert source time to UTC first, then UTC to server time. For daily loss rules, follow the reset timezone stated by the account rather than assuming local midnight.
Trading-platform server time is the clock used by the infrastructure that records chart bars and trade activity. A one-hour candle labeled 10:00 is built according to the server's timeline. A trade-history timestamp can also reflect that server clock. The server timezone is an operational choice and does not need to match the trader's physical location.
Server time is sometimes described as GMT+2, GMT+3 or another offset. In practice, traders should think in UTC offsets because “GMT” is often used loosely in platform documentation. If a server is three hours ahead of UTC, record UTC+3. If it changes to UTC+2 in another season, update the record.
The platform clock is not automatically the legal or contractual clock for every account rule. The prop program can state another timezone for daily resets or news restrictions. Always read the rule. Server time is important because it is how trades are stamped, but the controlling timezone is whatever the current account terms define.
A clean rule sheet therefore has separate lines for server time and rule time. If they are the same, write that explicitly. If they differ, the difference is visible before the session begins.
Your device normally uses the local timezone selected in the operating system. A trader in India sees IST, UTC+5:30. A platform server may be UTC+2 or UTC+3. Both clocks are showing the same moment using different labels.
Server location is not the only reason for the difference. Brokers and platforms can choose an offset that makes trading weeks, candle closes or operational processes convenient. The trader should not infer the server's physical location from its clock.
Travel creates another problem. A phone may automatically switch to a new local timezone while the platform server remains unchanged. If the trader's spreadsheet assumes the old local timezone, calendar conversions can become wrong even though the server did not move.
Label every clock with an abbreviation or offset. “18:00 IST,” “15:30 Server UTC+3” and “12:30 UTC” are clear. Three unlabeled numbers are not.
News rules can interact with server time because the platform records entry and exit timestamps. Daily loss or trading-day rules can also depend on a stated reset time. Minimum trading days, overnight boundaries and weekend logic may use another official clock.
Do not assume every daily drawdown resets at 00:00 server time. Some programs define a specific timezone. Others may use a calculation that is not simply a platform midnight reset. The exact terms control.
For automation, server time is especially important because many EAs read the platform's native timestamp. A filter coded to stop at 15:25 server can be wrong if the server changes from UTC+2 to UTC+3 and the code is not updated.
The practical lesson is simple: every time-based account rule should name its controlling clock in the trader's notes.
Prop Firm Bridge research note: Server time should be recorded as an offset, not guessed from a city or a platform brand.
Book insight: Mark Douglas, Trading in the Zone, Chapter 4, supports consistent operating rules. A trader should not change time logic in the middle of a live session.
Depending on the platform, server time can appear in the market watch, chart axis, order history, trade log or platform status area. The clearest live value is one that updates with the platform itself rather than a manually configured indicator.
Chart timestamps can help, but remember that a candle label can represent the start or end of a bar. Use the platform documentation when possible. Trade history can also reveal the clock, especially around an execution whose real-world time you know.
Do not use a screenshot from another trader as proof. Two accounts can run on different servers or environments. Measure the clock on the exact account.
Record the date of the measurement because offsets can change.
Open a trusted UTC clock and the trading platform side by side. Suppose UTC is exactly 12:00 and the platform shows 15:00. The server is currently three hours ahead, so record UTC+3. Repeat the comparison after several minutes to make sure both clocks advance together.
If the platform shows 14:00, the offset is UTC+2. If it shows 17:30, the offset is UTC+5:30. The arithmetic is simple once UTC is used as the neutral reference.
Then compare local time. An Indian trader at 17:30 IST can see a UTC+3 server at 15:00. That does not indicate a problem. It simply means local time and server time differ by two hours thirty minutes.
A written offset is more useful than a memorized clock difference because the local timezone can change when the trader travels.
Measure it and then ask support if a rule depends on precision. A live comparison gives the practical current offset, while a written support answer can clarify whether the offset is expected to change seasonally.
Ask a narrow question: “What UTC offset does the trading server use today, and does it change when daylight saving begins or ends?” That is clearer than asking “What time does the platform use?”
If support describes the server as GMT+2 or GMT+3, convert that into UTC+2 or UTC+3 in your notes. In ordinary offset use, that keeps the calculation clean.
Do not trade a strict boundary based on an unverified clock. If the server time is genuinely uncertain, use a wider personal buffer or remain flat until it is clarified.
Prop Firm Bridge research note: A one-minute clock check can prevent hours of confusion when reviewing a trade history later.
Book insight: Morgan Housel, The Psychology of Money, Chapter 13, is relevant because measuring the clock creates room for a small assumption to be wrong.
UTC does not change for daylight saving. Every local or server clock can be written as an offset from UTC. That makes it a stable bridge between the event source, trader location and platform.
Without UTC, a trader tries to remember many pairwise differences: New York to India, New York to London, London to server, local to server and so on. Those differences can change seasonally. With UTC, each clock only needs one relationship.
For a September BLS release at 8:30 a.m. EDT, the event is 12:30 UTC. If the server is UTC+3, it is 15:30 server. If the trader is in India, it is 18:00 IST. One neutral time creates both answers.
Keep a UTC clock visible on major news days if the account has strict time rules.
Subtract UTC from the server time at the same moment. If server time is 16:00 and UTC is 13:00, the server is UTC+3. If server is 11:00 and UTC is 13:00, it is UTC-2.
Be careful when the dates differ. If UTC is 23:30 and the server shows 02:30 on the next day, the server is UTC+3. Date rollover is part of the calculation.
Write the offset with a plus or minus sign. “Server 3” is ambiguous. “Server UTC+3” is clear.
Repeat after daylight-saving transition weekends because some servers shift.
Do not round. India Standard Time is UTC+5:30. If an event is 12:30 UTC, it is 18:00 IST. If it is 18:00 UTC, it is 23:30 IST. The half hour is part of the timezone.
Rounding IST to UTC+5 or UTC+6 creates a thirty-minute error, which is enormous compared with a short news restriction. Spreadsheet formulas should use 5.5 hours, not five or six.
If the platform server uses whole-hour offsets, the difference between server and IST can also contain a half hour. A UTC+3 server is two hours thirty minutes behind IST.
Write the local time with the timezone label so the half-hour structure stays visible.
Prop Firm Bridge research note: UTC removes most timezone complexity, but half-hour zones must still be kept exact.
Book insight: Annie Duke, Thinking in Bets, Chapter 1, supports a calculation that exposes assumptions instead of hiding them.
New York moves from EST, UTC-5, to EDT, UTC-4, on March 8, 2026. It returns to EST on November 1, 2026. A U.S. event listed as 8:30 a.m. ET therefore maps to different UTC times depending on the date.
During EDT, 8:30 a.m. ET equals 12:30 UTC. During EST, it equals 13:30 UTC. Indian and Japanese local times shift by one hour even though India and Japan do not change their own clocks.
Do not store “ET = UTC-5” as a permanent formula. Store both seasonal offsets and the change dates.
The umbrella abbreviation ET is useful for official schedules, but the converter must know whether the date is EST or EDT.
The UK clocks move forward on March 29, 2026 and back on October 25, 2026. During British Summer Time, London is UTC+1. During GMT, London is UTC+0.
The U.S. and UK change clocks on different dates. That creates short periods when the familiar London-New York difference changes by one hour. Traders who memorize session relationships can be surprised.
Use the date and UTC instead of assuming London is always five hours ahead of New York.
The same principle applies to economic events. A London local conversion must use GMT or BST according to the exact date.
Japan Standard Time is UTC+9. The National Institute of Information and Communications Technology states that Japan does not currently implement daylight saving time. That means the Japanese local offset itself remains stable.
However, a U.S. event still shifts by one hour in Japanese local time when New York changes between EDT and EST. The source moved relative to UTC; Japan did not.
This distinction is important. “Japan has no DST” does not mean “U.S. news is always at the same Tokyo clock time.”
Always convert through UTC so the change is handled correctly.
Prop Firm Bridge research note: DST changes are source or destination changes. A fixed local timezone can still see an event move when the source changes.
Book insight: Mark Douglas, Trading in the Zone, Chapter 7, is useful because the trader should expect environmental change rather than assuming a familiar pattern is permanent.
Many calendars detect or store a preferred timezone and convert events automatically. This is convenient until the setting is wrong. Travel, device changes or browser preferences can make the displayed time different from what the trader expects.
Always check the timezone label at the top of the calendar. If the calendar shows 18:00 for a BLS release while the trader is in India, confirm it is displaying IST rather than server time.
Automatic conversion should be treated as a tool, not a source of truth. The official agency schedule provides the original event time.
For a strict prop rule, write both the official and converted time in the note.
Take the exact date first. In September 2026, New York is on EDT, UTC-4. An 8:30 a.m. BLS release becomes 12:30 UTC. If the platform server is UTC+3, the event is 15:30 server. If the server is UTC+2, it is 14:30 server.
Then apply the formal blackout window in the same clock used by the rule. If the rule is stated relative to the event rather than a server timestamp, the duration is the same real-world interval after conversion.
Keep local time as a separate convenience value. In India, 12:30 UTC is 18:00 IST during both summer and winter because IST is fixed.
When New York returns to EST, repeat the conversion from the beginning. Do not reuse the September value.
Enter the statement and press conference separately. For September 16, 2026, the Federal Reserve lists 2:00 p.m. ET and 2:30 p.m. ET. During EDT, those equal 18:00 and 18:30 UTC.
A UTC+3 server shows 21:00 and 21:30. India shows 23:30 and 00:00 on the next local day. The date rollover should be written explicitly.
If the account rule uses one broad FOMC blackout, record the combined range. If it lists both events separately, keep two rows.
Do not assume the first FOMC spike is the end of event risk. The press conference is another scheduled communication point.
Prop Firm Bridge research note: The economic calendar and platform are two displays of the same event, not competing clocks.
Book insight: Morgan Housel, The Psychology of Money, Chapter 13, supports redundant verification around high-consequence events.
A prop program can define its daily loss calculation using a specific timezone, server boundary or another stated method. The trader's local midnight may be unrelated. A trader in India can cross local midnight while the account is still inside the same official trading day.
Never write “daily loss resets at midnight” without the timezone. Midnight needs a clock. If the rule says server midnight, use server time. If it specifies Eastern Time or UTC, use that instead.
Floating P&L can also matter depending on the calculation. A position carried across the reset can interact with a new daily baseline in ways the trader must understand from the actual terms.
Daily reset logic belongs on the same time sheet as news events.
A trader can open a position during the local evening and believe the same day continues for several hours. The server may already be close to midnight. When the server date changes, the account's daily calculation may enter a new period if that is how the rule is defined.
This can matter for risk allocation. A trader should know whether the open loss, prior balance or equity is used in the new day's formula. The exact mathematics differs by program, so do not generalize.
Mark the reset in local and server time. If the server changes offset seasonally, check whether the local reset time moves too.
Swing traders should review this before holding positions overnight.
Write the controlling rule first: for example, “Reset defined by X timezone in current terms.” Then write the converted local time and the current server equivalent. Keep the date of the check.
If the account says 00:00 server and server is UTC+3, an Indian trader sees that moment at 02:30 IST. If the server later moves to UTC+2, the local equivalent becomes 03:30 IST. This example shows why the current offset matters.
Do not assume this example applies to a particular firm. It is only a conversion method. The actual reset definition must come from the live account rule.
Use an alert if the strategy regularly carries positions near the boundary.
Prop Firm Bridge research note: Daily loss math and server time should be reviewed together whenever a strategy holds across sessions.
Book insight: Annie Duke, Thinking in Bets, Chapter 1, fits because knowing the exact rule is part of making the decision before the outcome.
A server several hours ahead of UTC can cross midnight before a trader in another region. A market reopening late Sunday in one timezone can therefore appear on a Monday server date.
This does not mean the market opened a day later. It is a labeling difference created by the server offset. Trading-week calculations should follow the account or platform definition rather than the trader's casual calendar language.
Weekend gaps can also make the first tradable price different from Friday's close. A swing trader should manage market risk separately from the clock label.
Record the platform's weekly opening behavior if the strategy depends on Sunday or Monday candles.
A candle marked 08:00 server may correspond to a different London or New York local hour depending on the server offset and daylight-saving season. Session indicators that are coded with fixed server hours can become wrong after an offset change.
Use UTC-based session definitions when possible. Then map the current server time dynamically or update the inputs after seasonal shifts.
A trader who says “I trade the London 8 a.m. candle” should specify whether that means 8 a.m. London local time or a candle labeled 8 a.m. on the server.
This distinction becomes especially important for backtests.
Check the account's overnight rules, daily reset definition, weekend restrictions, upcoming economic events and current drawdown. A position can be compliant to hold and still be too risky because a major event occurs before the trader returns.
Review whether stop-loss and take-profit executions are treated differently during news windows. A swing position can cross a blackout while the trader is away.
Confirm the local time of the next reset. If a server offset has changed, the trader's old reminder can be wrong.
The holding decision should combine market, time and rule risk.
Prop Firm Bridge research note: Weekends expose hidden clock assumptions because calendar dates can differ across server and local time.
Book insight: Mark Douglas, Trading in the Zone, Chapter 4, supports defining session and time rules before the trade is opened.
At minimum, a time-sensitive prop trader benefits from seeing UTC and the platform server. Local time can be the third clock for convenience. If the trader mainly uses local time and has no automated server logic, local plus UTC may be enough as long as server time is documented.
The goal is not to fill the screen with clocks. It is to make the conversion obvious. One small UTC clock, the platform's server clock and the device's local clock can solve most timing questions.
Label each one clearly. Do not rely on position or color alone.
Use a 24-hour format if it reduces a.m./p.m. mistakes.
Official event time converts to UTC once. Every destination clock is then derived from the same reference. If NFP is 12:30 UTC, the trader can see whether the server and local clocks line up with the expected conversion.
UTC also makes it easier to compare multiple accounts. A UTC+2 and UTC+3 server differ by one hour, but both can be checked against the same event timestamp.
For FOMC, the 18:00 UTC statement and 18:30 UTC press conference are easy anchors even when local dates change in Asia.
Use UTC as the backbone and local time as the convenience layer.
A complex dashboard can create more confusion than it removes. The trader should be able to answer “What time is it in UTC, what time is the server, and when does my rule start?” in seconds.
Do not add five timezones if only three matter. Do not use unlabeled analog clocks. Do not depend on a spreadsheet that requires manual refresh in the final minute.
Test the setup on an ordinary day before relying on it during CPI or FOMC.
The best operational tool is one the trader actually checks.
Prop Firm Bridge research note: Time tools should reduce cognitive load. More clocks do not automatically mean more safety.
Book insight: Morgan Housel, The Psychology of Money, Chapter 13, supports simple systems that reserve attention for the decisions that matter.
Trading code frequently reads the platform's current timestamp. Entry windows, session filters and daily resets can therefore be based on server time unless the programmer explicitly converts to UTC or another timezone.
A strategy can appear to trade “London open” correctly for months and then shift by one hour when the server or London changes daylight-saving state. The code did not become random; the hidden time assumption changed.
Every automated strategy should document its time basis. “Uses server time” or “uses UTC” is a critical technical setting.
Do not assume an EA purchased from another trader uses the same timezone as the account.
Suppose an EA blocks entries from 15:25 to 15:35 server time for an 8:30 ET event. That mapping is correct only for a specific combination of ET offset and server offset. When either changes, the filter can miss the actual event.
A robust system can convert the event dynamically or use UTC. If that is not possible, the trader needs a manual seasonal update.
Test the filter after U.S., UK and server clock transitions. Check actual logs rather than assuming the code changed correctly.
A one-hour error is large enough to remove the protection completely.
Verify the current server offset, inspect the EA's timezone setting, simulate or review the blocked period, confirm pending orders are handled and check whether copied trades can bypass the filter.
Run the test before the event day if possible. A live CPI session is not the right time to debug a timezone function.
Keep a manual emergency stop available. If automation is uncertain, disable it.
Document changes so the same problem does not return at the next seasonal shift.
Prop Firm Bridge research note: An automated strategy can be mechanically consistent and still consistently wrong by one hour.
Book insight: Annie Duke, Thinking in Bets, Chapter 1, supports testing the process rather than trusting a good past outcome.
Give every account a clear label that includes platform and current server offset. Do not keep one generic “server time” field in a multi-account spreadsheet.
The same event has one UTC time but can have several server timestamps. Use UTC as the common row and separate server columns for each account.
If the accounts also have different news rules, keep the compliance fields separate. The time may be easy; the allowed action can differ.
Review each account before a major release rather than assuming copied positions are synchronized.
Include account name, stage, server offset, rule timezone, daily reset timezone, local conversion, current news window and date checked. For automation, add the EA time basis.
One master event column can show NFP 12:30 UTC. Account A might show 14:30 server and Account B 15:30 server. The trader can see both without duplicating the event.
Use filters or a simple active-account view so the matrix remains readable.
Archive closed accounts to reduce clutter.
Set alerts from UTC or local time rather than server time when the alerting app does not know each account server. Then write the server equivalents in the alert description.
A personal no-trade buffer can also be standardized across accounts if it is wider than every formal rule. This simplifies behavior but must remain a personal policy.
For copied trading, stop the source early enough that destination accounts also remain outside restricted windows despite small delays.
The goal is one clear action across many clocks.
Prop Firm Bridge research note: Multi-account trading becomes safer when UTC is shared and server offsets remain account-specific.
Book insight: Mark Douglas, Trading in the Zone, Chapter 4, supports a standard process that remains clear across different accounts.
Stop relying on the old conversion. Compare the platform with UTC again. Check whether a daylight-saving change, platform maintenance, server migration or account change occurred.
Update every time-based tool after confirming the new offset. That includes calendar notes, EAs, session indicators and reset reminders.
If the shift is unexpected and unexplained, ask official support before trading a strict news boundary.
Do not assume the platform will return to the old time later.
Maintenance can move an account to another server or temporarily affect displayed data. Daylight-saving changes can intentionally move the server offset. Historical candles may remain stamped according to the platform's conventions.
A trader comparing old and new screenshots can therefore see apparent inconsistencies. Use current live measurements for current rules.
For backtests, document the historical offset method if session timing matters. A fixed offset across many years can distort results.
For live compliance, the current rule and current server matter most.
Contact support when the server offset cannot be identified reliably, when the rule references server time but the platform clock is unclear, when a reset appears inconsistent or when a platform migration occurs.
Ask a specific question and include the account model. Request the current UTC offset and whether it changes seasonally.
Keep the answer with the date. If the public documentation later changes, verify again.
Do not use support as a substitute for simple arithmetic, but use it when the controlling rule is genuinely ambiguous.
Prop Firm Bridge research note: Unexpected time changes should trigger an audit before the next event, not a guess.
Book insight: Morgan Housel, The Psychology of Money, Chapter 13, supports stopping to create room when an important assumption suddenly becomes uncertain.
Record local timezone, current server offset, rule timezone, daily reset definition, news-event source and account stage. Measure the server against UTC and save the date.
Check whether automation uses server or UTC time. Set the economic calendar to a known timezone. Add a current UTC clock to the workspace.
Save official rule links rather than screenshots only. A link makes future verification easier.
Complete this setup before the first high-impact trading day.
Recheck New York's EST/EDT status, London's GMT/BST status, the platform server offset and every automated time filter. In 2026 New York changes March 8 and November 1, while the UK changes March 29 and October 25.
Fixed-offset zones such as India and Japan do not change, but their relationship to New York and London still changes when those source clocks move.
Update spreadsheet formulas and alerts. Test one known event conversion from source to UTC to server.
Do not wait for a missed trade to reveal the old offset.
Confirm the official event date and source time. Convert to UTC. Confirm server offset. Calculate server and local time. Add the current account's formal news restriction. Review open and pending orders.
For FOMC, enter the statement and press conference separately. For NFP and CPI, confirm the monthly schedule rather than using a permanent recurring date.
Check remaining drawdown and decide whether a permitted hold is still worth the risk.
After the event, use the platform trade history to confirm the timestamps matched the expected conversion. That becomes a useful audit for the next session.
Related Prop Firm Bridge reading: See News Trading Time Zones, How to Trade News Events Without Breaking Rules, and the 30-Minute Rule guide.
Prop Firm Bridge research note: A permanent checklist turns server time from a hidden technical detail into a controlled trading variable.
Book insight: Annie Duke, Thinking in Bets, Chapter 1, fits the final checklist because assumptions are safer when they are written and tested.
The structured FAQ summarizes the main server-time questions. For a live account, the current platform clock and the account's own time-based rules always take priority over a generic example.
About the Author: Akash Mane
Akash Mane is the Founder and CEO of Prop Firm Bridge. His work focuses on data-backed prop firm research, verified account-rule analysis and practical education that helps traders make informed decisions. Connect with him on LinkedIn.
Conclusion
Server time becomes simple when it is treated as its own clock. Measure it against UTC, record the current offset and stop assuming it matches local time. Then use one conversion chain for every event: official source time → UTC → server time and local time.
Recheck the system after daylight-saving changes and platform migrations. Keep daily reset rules separate from news rules. Audit automation for server-time assumptions. A trader who controls the clock removes one of the easiest ways to make an avoidable prop evaluation mistake.
Prop Firm Bridge helps traders understand prop firm rules, timing mechanics and evaluation risk through verified, data-backed research. Visit propfirmbridge.com for current prop trading education.
Server time is the clock used by the trading platform or broker infrastructure for chart candles, trade timestamps and sometimes rule calculations. It can differ from both the trader's local time and the official event-source time.
Compare the live platform clock or candle timestamp with a trusted UTC clock. The difference shows the current server offset. Recheck it after daylight-saving transitions or platform changes.
A prop firm news restriction can be defined around an event time while the platform records the trade in server time. Converting the event incorrectly can place an entry or exit inside a restricted window.
Some daily loss calculations or trading-day boundaries can depend on a specified reset timezone. A trader should know whether the rule uses server time, another stated timezone or a different calculation.
No. Some platforms use those offsets, but there is no universal server timezone. The current offset must be measured or confirmed for the exact account.
Yes, some trading servers change their UTC offset seasonally. Traders should recheck the clock around daylight-saving transitions and update EAs, calendars and spreadsheets.
Convert the official event time to UTC using the correct seasonal offset, then convert UTC to the platform's current server offset. Keep local time as a separate convenience clock.
Japan Standard Time itself does not use daylight saving and remains UTC+9, but the event source or platform server may change offset, so the overall conversion can still change.
India remains UTC+5:30, so traders should keep the half-hour offset exact. Convert event time to UTC first, then add 5 hours 30 minutes for IST and separately apply the server offset.
Record the account stage, platform server offset, rule reset timezone, economic-calendar timezone, local timezone and the date checked. Recheck after platform migrations and daylight-saving changes.
