I have an application that operated fine in this environment:
Raspberry Pi 3
Buster OS
Xojo application compiled w/Xojo Version 2020r2.1
Yesterday I recompiled the application with Xojo Version 2025r2.1 and the application errored when starting. I tried for several hours to track down the problem and finally determined that my application was crashing on this line of code:
Var Now_dat As DateTime = DateTime.Now
The error was this:
An exception of class InvalidArgumentException was not handled. The application must shut down.
Exception Message: Bad Timezone name: posixrules
The only thing that changed was the use of a newer version of Xojo. I spent the rest of the day using ChatGPT to try and figure out how to fix the issue. Finally, ChatGPT offered a fix:
sudo ln -sf /usr/share/zoneinfo/EST5EDT /etc/localtime
This fixed the problem but left me uneasy wondering why this issue happened in the first place.
I asked ChatGPT to provide a summary of the issue and it delivered this (if you are interested):
I dug into it, and I think we can now explain the whole sequence with considerably more confidence.
The short version: your Raspberry Pi’s timezone configuration was not newly corrupted. The America/New_York → posixrules arrangement is an old, legitimate Debian/tzdata design. What changed is almost certainly the Xojo runtime’s handling of the Linux local timezone, not the Pi’s clock or timezone configuration.
- Your Pi’s posixrules arrangement is legitimate
This was the part I initially misdiagnosed.
Debian’s tzdata has historically generated posixrules as a link to America/New_York. The tzdata build configuration explicitly says that America/New_York is the default template for POSIX-style timezone rules.
In fact, Debian’s documentation/manpages describe:
/usr/share/zoneinfo/posixrules
as the timezone file used for certain POSIX DST rules, and say that it is normally linked to the America/New_York tzfile.
So your original:
/etc/localtime
↓
America/New_York
↓
posixruleswasn’t some bizarre corruption that happened recently.
- Your installed tzdata hasn’t changed recently
You have:
tzdata 2021a-0+deb10u3
Debian’s changelog confirms that 2021a-0+deb10u3 was released in October 2021. Subsequent Buster updates existed, including deb10u4 and deb10u5, but those updates were for specific timezone/leap-second changes—not a fundamental change to how America/New_York works.
So there’s no evidence that some recent tzdata update suddenly caused this.
In fact, your Pi’s timezone files have timestamps from October 25, 2021, which fits that story perfectly.
- Linux itself is completely happy
We proved this experimentally.
Linux:
date → EDT -0400
timedatectl → America/New_York
Python → (‘EST’, ‘EDT’)
Python DST → 1
Python localtime → correctSo the OS timezone subsystem is functioning.
- The smoking gun is Xojo’s exception
Your Xojo program produced:
InvalidArgumentException
Bad Timezone name: posixrulesThat is extraordinarily useful.
Xojo’s current documentation says:
DateTime.Now(timeZone As TimeZone = Nil)
and explicitly says that when the timezone argument is Nil, it uses the device’s current timezone.
Therefore your:
Var Now_dat As DateTime = DateTime.Now
causes Xojo to discover the Pi’s timezone.
Somehow, on this Linux configuration, the Xojo runtime is discovering:
posixrules
instead of:
America/New_York
and then attempting to create a Xojo TimeZone named posixrules.
That produces exactly the exception you saw.
- There’s evidence that Xojo’s timezone handling has had problems before
This isn’t unprecedented in Xojo.
There are reports of Xojo throwing Bad Timezone name exceptions when its runtime encounters OS timezone representations that don’t map cleanly to the timezone names Xojo expects. One 2019 report involved DateTime.Now and a system timezone configuration; another Xojo discussion specifically describes problems when a system timezone name isn’t one Xojo recognizes.
There’s even a much more recent Linux report where a Xojo application complained about:
Bad Timezone name /etc/localtime
even though /etc/localtime pointed at a perfectly legitimate IANA zone such as America/Chicago.
That makes your experience look much less like a damaged Pi and much more like a weakness in Xojo’s Linux timezone discovery.
So what actually changed?
This is the one part where I want to be precise.
I cannot find a Xojo release note that explicitly says:
“Changed Linux DateTime timezone detection and now follows /etc/localtime symlinks to posixrules.”
The 2025 R2 release notes don’t document such a change.
Therefore I don’t want to claim that we’ve proven a specific Xojo release introduced this bug.
But we have proven the behavioral change:
Previously
Your old Xojo runtime:
/etc/localtime
↓
America/New_York
↓
posixrulesdidn’t cause a problem.
Now
The newer Xojo runtime:
/etc/localtime
↓
America/New_York
↓
posixrules
↓
Xojo interprets “posixrules” as timezone name
↓
InvalidArgumentExceptionAnd when we changed only:
/etc/localtime
to point directly at:
/usr/share/zoneinfo/EST5EDT
your unchanged Xojo application immediately started working.
That’s a very strong causal demonstration.
Why did EST5EDT fix it?
Because EST5EDT is an actual tzfile:
/usr/share/zoneinfo/EST5EDT
rather than a symlink whose final component is:
posixrules
So Xojo’s apparently simplistic discovery mechanism no longer encounters the string posixrules.
The underlying timezone rules are still Eastern Standard/Daylight Time, so Linux continues to report:
EDT -0400
and your application gets its DateTime.Now.
One interesting wrinkle
There is actually an even better clue in the current Debian tzdata source.
Modern Debian’s tzdata build process deliberately creates posixrules as:
ln -s America/New_York …/posixrules
and Debian’s own source comments acknowledge that POSIXRULES is an old/obsolete mechanism.
So the Linux ecosystem has been moving away from depending on posixrules, while your Buster installation is still using the old arrangement.
That makes the most likely overall explanation:
Your Pi’s old Buster timezone database was perfectly valid, but a newer Xojo Linux runtime became less tolerant of the old posixrules representation.
And this explains the timing
Your application could quite reasonably have run:
2017 → 2025/2026
without a problem.
The Pi didn’t necessarily change at all.
You eventually rebuilt it with a much newer Xojo runtime, and that runtime encountered an old-but-valid Linux timezone arrangement that the older Xojo runtime had tolerated.
That’s why it seemed like:
“It has worked for years and suddenly the Raspberry Pi is broken.”
It wasn’t actually the Pi’s clock that broke.
It was the interaction between an old Linux timezone representation and a newer Xojo runtime.
I think your current fix is perfectly reasonable
You’ve changed:
/etc/localtime
→ /usr/share/zoneinfo/EST5EDTand your Xojo application works again.
I would leave it that way rather than changing anything else. We now have a working configuration, and there’s no reason to disturb it.
So, what actually changed in the time between Xojo 2020r2.1 and Xojo 2025r2.1? Is this something that needs to be addressed or is Xojo 2025r2.1 simply not going to work with Raspberry Pi Buster?