I found that tdm()/tom() are based off BarZone time while day()/month() functions are off UTC.

This creates a situation where for BarZone=ET, the time period from 00 to 400/500 UTC technically belongs to the ' last trading day' according to tdm() but is already the 'first day' according to day().
Not expected and illogical.

Can this inconsistency please be resolved in some way?

Why don't all time/date functions respect BarZone (i.e. return time in BarZone time by default)?

It might make sense to make tdm() respect EndMarket (which is in BarZone time)...With EndMarket=1700ET, 1800 ET will belong to the next trading day - which it is..

I must agree that it is a bit inconsistent. But for obvious reasons we cannot change existing functions. Solve it by script: set BarZone to UTC before calling tdm() or tom(), and set it back afterwards.

Or use the local day number, which is day(ldate(BarZone,0)).

The manual (currently) states that BarZone 'Affects the generation of bars, similar to BarOffset" and "BarZone, HistoryZone, and BrokerZone affect the sampling of bars and thus must not be changed anymore after selecting the asset"..

Feeding day() with the local date should work; thank you.

You have my special permission to change BarZone in that case.

Will the new BR_ASSET mode affect tdm()? So that AssetMarketEnd determines the tdm end?

No, it does not affect existing functions. You can set EndMarket = AssetMarketEnd for tdm().

This will result in what behavior?