I was recently (in #5285) made aware that timezone information was removed about a year earlier, in #3583. I would have said something sooner had I been aware sooner, but I think it was a mistake.

There are many aspects of this, but at the core is that I think a timezone is a fundamental part of any date/time specification, if spoken or written. 2026-02-14 10:00 doesn't mean much if you don't know what timezone is referred to. So, the whole notion that a timezone is just a "troubling detail" that we are better off without, simply isn't true. You can't get rid of timezone if you want to use the "standard" date/time specifications that most of us use. The reason is that the time is set according to the daylight schedule, and that doesn't take place at the same time around the world. Any ideas of "getting rid of" or "we don't need" timezones are simply wrong. That's impossible to do without using another date/time system.

What we can do, is to say that "only one timezone matters, all others are irrelevant". China has done so, with "China Standard Time", where Beijing time is forced upon everyone in China, despite the fact that the country geographically spans five time zones. This makes some things very simple and other things very inconvenient. The US military has done a similar thing, where they use UTC exclusively (although they call it "Zulu time"). There's a "trend" in computing to also move towards UTC to not have to deal with timezones on "system levels". I think it makes sense to simplify e.g. online APIs to use UTC in cases where the timezone doesn't matter, only the moment in time does.

But, I think it's a mistake to think of OH as such a system. Every time a moment in time is to be expressed using the standard notation, a timezone must be "acquired" and applied. If you have a web app where all the data is stored on some datacenter, and each user interfaces exclusively using a web browser, it's easy to use UTC for all storage and calculations in the datacenter, and then convert it to the browser's configured timezone before presentation. OH doesn't have this structure at all, instead, the users come in contact with the data frequently and through various channels. There are lots of different ways the "paths cross" between the users and the data, and there's no "clean cut" browser setting that can be applied universally.

We have two or three sources of timezone information to work with:

• The JVM default timezone
• The OH configured timezone
• The browser timezone when the UI is involved

In Java code, the JVM default timezone (although unsuitable) is always available. In the UI the browser timezone is always available. Other than that, there are generally challenges with accessing the timezone information, which is at the root of this whole "problem". The OH configured timezone, which is the one that should be used in almost every situation, is made available through the TimezoneProvider OSGi service. As a result, it's only available to other OSGi components, and a lot of the code that need it, simply have no way of acquiring it, which is a major argument for storing the timezone with the DateTimeType instance itself.

These timezones are often the same, in which case, bugs and shortcomings are effectively hidden. They aren't always the same, and if you try to use OH today with a mismatch between the JVM default timezone and the OH configured timezone, things won't work very nicely, because it varies which one is applied. I don't think the browser timezone is currently used for anything. #3583 even states that "there will be issues" if these mismatches.

I am of the long-standing opinion that the JVM default timezone should be avoided like the plague. It's simply not reliable. It defaults to follow the host OS' configured timezone, but there are numerous ways it can be changed, intentionally or unintentionally. If you use a hosting service, you might not even be able to set it to what you want. And, anything that runs on the JVM can change it at any time. Any user script can change it, not long ago somebody found a bug in GraalPy that if you call a certain formatting function, the JVM default will be changed. And, it's not thread-safe either. In short, I consider it a completely unreliable source that should be avoided if at all possible. This is in stark contrast to the current arrangement, where it is "required" to be in sync with the OH configured timezone for things to work.

I think it's correct that OH has a configurable timezone, but when that exists, it must be the source used, not the JVM default timezone. Otherwise, it would be better if OH didn't have a timezone setting and everything relied on the unreliable JVM default timezone. At least things would be consistent. So, I see this as undermining the very point of having a configurable timezone in OH.

But, it doesn't stop there. Letting a date/time carry its own timezone information is also very convenient. It means that you'll always have a timezone at hand when you need to present it as text. As it is now, unless you find it acceptable that everything is in UTC, you must come up with a timezone every time you want to display, log or store a moment in time. As a result, some things are now logged using UTC, confusing users. And, scripting has become a lot more complicated, as the responsibility to acquire a timezone has been shifted from those that provide the "moment in time" to those who want to deal with it or consume it. It's quite obvious to me that most "moments in time" are consumed or otherwise dealt with more than once - which means that the net total of situations where a timezone must be acquired has increased. The most efficient thing is to acquire it at creation.

Since scripting has been severely affected by this change, efforts have been put into the scripting "helper libraries" to make date/times less inconvenient to deal with. From what I understand, it's still nowhere near what it was, and that is only logical: There's no way to get around the fact that when you throw away the timezone information, it must be acquired somehow, and there's a limit to how much "help" can be given here. Rule DSL has been described as "broken" following this change, and it looks like there is nothing that anybody can do to remedy this. In addition, we have scripting languages without "helper libraries", and they have really got their workload increased.

There are other problems as well, I've tried to only mention what I consider the most essential issues here, but one thing that might also need mentioning is the subtle bugs introduced when calculating durations between two timestamps or finding moments in time in the past or future, without knowing which timezone you're in - which will lead to bugs when you cross daylight saving boundaries.

I really hope that the decision can be reevaluated, as far as I've been able to figure out by reading various issues, PRs and forum threads, the only thing that got "better" by removing the timezone is that binding authors no longer have to deal with providing a timezone when "creating timestamps". Everything else is worse off.