Is it still best to stick with UTC times after the introduction of <chrono>?

Not necessarily. C++20 introduces local time arithmetic which can be very useful in a surprising number of circumstances. Local time arithmetic can be contrasted with UTC arithmetic to make your code more robust in the face of daylight saving time. I'm not saying local time arithmetic is better than UTC arithmetic. It is not. I'm just saying that sometimes it is the right tool for the job.

To illustrate, I have an example below that models the nightly routine of a popular BBQ restaurant. The restaurant opens at 7 in the morning, and closes at 10pm (22:00) in the evening. At closing time, two things happen:

1. A security guard comes to work to keep the BBQ secure while it cooks for the next day.

2. The smoking of the next day's meat begins. The meat must cook for exactly 9 hours; not 8, not 10. It should be ready when the restaurant opens at 7am the next morning.

So on a normal evening:

• At 10pm the security guard arrives, and the meat is put into the smoker.

• At 7am the next morning, the security guard leaves and the meat is removed from the smoker.

The security guard must be paid for each hour worked. And the meat must be cooked for exactly 9 hours and ready at 7am sharp.

Twice a year in America/New_York the politicians mess with this carefully crafted schedule by changing the local time discontinuously at 2am. The nightly routine must accommodate these daylight saving changes so that the guard is paid for each hour worked, and the meat is not over- or under-cooked.

#include <chrono>
#include <iostream>

void
nightly_routine(std::chrono::local_days dt, std::chrono::time_zone const* tz)
{
    using namespace std;
    using namespace chrono;

    // dt is the local midnight which starts a date

    // security guard works from 10pm on the previous day to 7am local time
    zoned_time sg_end{tz, dt + 7h};  // 7am local time

    // Subtract 9 hours in local time to always get 10pm the previous evening
    zoned_time sg_beg{tz, sg_end.get_local_time() - 9h};

    // Actual number of hours worked, usually 9h, but not always
    auto sg_hours = sg_end.get_sys_time() - sg_beg.get_sys_time();


    // bbq must cook for 9h and be ready at 7am local time
    zoned_time bbq_end{tz, dt + 7h};  // 7am local time

    // Subtract 9 hours in system time to reliably get 9h of cooking time
    // Usually this is 10pm the previous evening, but not always
    zoned_time bbq_beg{tz, bbq_end.get_sys_time() - 9h};

    // Actual number of hours cooked, always 9h
    auto bbq_hours = bbq_end.get_sys_time() - bbq_beg.get_sys_time();

    cout << "nightly routine for " << dt << " in " << tz->name() << "\n\n";

    cout << "security guard begins at   " << sg_beg << '\n';
    cout << "security guard finishes at " << sg_end << '\n';
    cout << "security guard works " << sg_hours/1h << " hours\n";

    cout << '\n';

    cout << "bbq begins cooking at   " << bbq_beg << '\n';
    cout << "bbq finishes cooking at " << bbq_end << '\n';
    cout << "bbq cooks for " << bbq_hours/1h << " hours\n\n";
}

int
main()
{
    using namespace std::chrono;
    auto tz = locate_zone("America/New_York");

    nightly_routine(local_days{January/1/2026}, tz);
    nightly_routine(local_days{Sunday[2]/March/2026}, tz);
    nightly_routine(local_days{July/1/2026}, tz);
    nightly_routine(local_days{Sunday[1]/November/2026}, tz);
    nightly_routine(local_days{December/1/2026}, tz);
}

Demo

• Local time arithmetic is used in the sg_end constructor to add 7 hours to the local midnight to get 7am local time. If UTC arithmetic were used here, it would not result in 7am local when there is a 2am daylight saving change.

• Local time arithmetic is used in the sg_beg constructor to subtract 9 hours in local time to get the security guard's arrival time. This will always be 22:00 local the previous evening, even when there is a 2am daylight saving change. This also could have been coded as dt - 2h, but I wanted to contrast this local time computation with the UTC computation used for finding the time to put the meat in the smoker.

• UTC arithmetic is used to get the number of hours the security guard worked. This is usually 9 hours, but in this time zone can also be 8 hours or 10 hours.

• The ending time for the BBQ uses the exact same local time arithmetic as the ending time for the security guard to reliably get 7am local.

• The beginning time for the BBQ subtracts 9 hours using UTC time arithmetic. Contrast this with the computation for sg_beg which used local time arithmetic. Unlike the security guard, who may work 8, 9 or 10 hours, the meat must be smoked for exactly 9 hours. And so UTC arithmetic is now the proper tool.

• As a sanity check, the number of hours the meat is smoked is computed in UTC time. This is an unnecessary computation as it will always be 9 hours.

The output of this program is:

nightly routine for 2026-01-01 in America/New_York

security guard begins at   2025-12-31 22:00:00 EST
security guard finishes at 2026-01-01 07:00:00 EST
security guard works 9 hours

bbq begins cooking at   2025-12-31 22:00:00 EST
bbq finishes cooking at 2026-01-01 07:00:00 EST
bbq cooks for 9 hours

nightly routine for 2026-03-08 in America/New_York

security guard begins at   2026-03-07 22:00:00 EST
security guard finishes at 2026-03-08 07:00:00 EDT
security guard works 8 hours

bbq begins cooking at   2026-03-07 21:00:00 EST
bbq finishes cooking at 2026-03-08 07:00:00 EDT
bbq cooks for 9 hours

nightly routine for 2026-07-01 in America/New_York

security guard begins at   2026-06-30 22:00:00 EDT
security guard finishes at 2026-07-01 07:00:00 EDT
security guard works 9 hours

bbq begins cooking at   2026-06-30 22:00:00 EDT
bbq finishes cooking at 2026-07-01 07:00:00 EDT
bbq cooks for 9 hours

nightly routine for 2026-11-01 in America/New_York

security guard begins at   2026-10-31 22:00:00 EDT
security guard finishes at 2026-11-01 07:00:00 EST
security guard works 10 hours

bbq begins cooking at   2026-10-31 23:00:00 EDT
bbq finishes cooking at 2026-11-01 07:00:00 EST
bbq cooks for 9 hours

nightly routine for 2026-12-01 in America/New_York

security guard begins at   2026-11-30 22:00:00 EST
security guard finishes at 2026-12-01 07:00:00 EST
security guard works 9 hours

bbq begins cooking at   2026-11-30 22:00:00 EST
bbq finishes cooking at 2026-12-01 07:00:00 EST
bbq cooks for 9 hours

One can see that, although the normal start time for smoking the meat is 10pm, sometimes it needs to go into the smoker as early as 9pm, and sometimes as late as 11pm.

The take-away here is that local time arithmetic can be very useful, in addition to arithmetic in UTC. The hard part is understanding your domain well enough to know which tool is right for the job.

TL;DR

Use UTC for all storage and calculations. Convert to/from local format only for User Experience (which <chrono> is perfectly fine for but which was quite possible before already). Be aware of the possible traps.

Your question is conflating two disjunct topics:

Sticking to UTC for all backend storage, logging, and internal logic is widely considered the gold standard in software engineering. You only convert to local time zones or offsets when strictly necessary for human input or display.

I strongly support this notion.

Date formatting differs by locale, sometimes ambigously so. 2/7/2026 could be June, or February. The year 1440 might be medieval, or current, depending on locale (and / or context). Basically the only immediately recognizable, unambiguous format here is YYYY-MM-DD. It is also naively sortable. Any other formatting would require the accompanying information of the locale active at the time of writing. That locale would then also be employed upon reading. As soon as clients might use your software under different locales, that can get ugly fast.

Locale identifiers are platform-dependent. en_US, en-US, 0x0409, or en_US.UTF-8? And what the heck is th-TH-u-ca-gregory? Is your non-UTC date handling logic up to handling each of those correctly? Are you aware that this is only the overall locale, and that the date locale of any given environment can be different from e.g. the message locale?

Time zone identifiers are ambiguous. If you think ahead and tag your timestamps with time zone identifiers, you need to be aware that for example 'CST' refers to four distinct time zones: China Standard Time, Cuba Standard Time, and two different versions of Central Standard Time (one in America, one in Australia). So your timestamps still aren't unambiguous.

That's just the usual highlight list. I could go into the proper handling of jump seconds next, i.e. when a minute has more or less than 60 seconds (which happens more often than you probably think).

The last point gets all this into sharp perspective though:

The next guy working with your timestamps might be unfamiliar with your locale. Think having some offshore freelancer looking for some specific bug, comparing database entries with logged error messages. He knows his UTC offset (hopefully). He can get your UTC offset easily enough. Knowing when exactly your timezone switches to DST and back, and whether your timestamps are properly tagged DST or not*, can easily throw off things.

UTC timestamps are universal, unambiguous, and precise. Use them for everything that is not customer-facing.

Compare:

7.6.26, 09:54 MET

"What is MET? Is that July 6th, or June 7th? Wait, that's in the summer, shouldn't that be MEST? Is that morning, or afternoon?"

2026-06-07 07:54 +0200

That's June 7th, shortly before 10 o'clock in the morning locally, 8 o'clock UTC.

Is this still true in (C++20 and later)? If not, how does enable manipulation of and computation within time zones, and what is a concrete example of when this is useful?

We had workable manipulation and computation of time zones all the way back in C! This is a completely different issue though. This is about how to turn those unambiguous UTC timestamps into local timestamps for client-facing code (if that is your decision -- if your application is about precision, a UTC timestamp might be well appreciated even by the customer).