23/8/18 is OK in Panorama X but illegal in Panorama 6.0

My System Prefs are set to Australian (non-US) conventions. This works fine in Panorama X where “23/8/18” is recognised as 23 August but Panorama 6.0 rejects it as illegal. Why?

Panorama X is definitely smarter about non US format dates than Panorama 6 was. Just another reason to transition to Panorama X as rapidly as possible.

What can I do about it? Will I have to restructure all text dates before converting to dates? I don’t recall having that problem before.

I’m actually time-travelling - backwards - I’m writing a farm management system in Panorama 6.0 for a Windows machine.

Panorama 6.0 is amazingly clunky after a year or more on Panorama X.

Sorry, I have no idea. I don’t even have a Windows computer to try it on.

I hope whomever is using this system is planning to stay backwards in time. Panorama 6 does not run at all on recent versions of Windows 10 (for almost a year now).

I prefer to think of it as Panorama X is amazingly cool! :slight_smile:

Pan 6 has a customnumbers statement that can help in procedures.

But how do I overcome the problem in a field in the data sheet?

Text funnels. As the existing data would produce the illegal date error, leave it as text, create a new field and do a formulafill with a formula that changes your data from “DD/MM/YY” to “MM/DD/YY”:


Then you can make the new field a date field — and you may be able to give that field an Australian output pattern.

Or you can look at the date as an array separated by the character “/”.

That’s what I’ve been doing - which is more forgiving than the text funnel method - but, in the olden days (pre-Panorama X), I could just enter a text date in Oz format and it would be accepted. I’m baffled as to why that’s no longer the case.

There is nothing that has changed about the way Panorama 6.0/5.5/5.0, etc. handles dates in at least a decade. If something has changed, it is not on the Panorama end. Maybe some change in Windows?

I’m writing the system on an iMac in OS 10.13.4 for later porting to Windows. Maybe macOS has changed.

It’s not a big deal, I plan to leave Panorama 6.0 behind anyway, other than this task for my next-door neighbour, and I’ll try to talk her into using a dedicated Mac (my office is currently cluttered with them) for this app and I can write it in Panorama X.

If nothing changed in Panorama, then it must be an Apple API that changed, or something else on the computer.

Michael, Ive had this problem in Oz for years and raised the issue on QNA, and you actually tested a date for me on your system. It started about four or five years ago on some Macs and on some OSX releases. I was forced to change formats within date( functions using text funnels when the system did not return a “correct” Oz date. It was an easy fix but rather tiresome to have to hunt down every case of date( use in my many P6 files.

Thanks for that confirmation David. It’s interesting how little OS tweaks to fix one problem or achieve a new goal can so totally upset pre-existing processes.