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


#1

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?


What is the latest Windows OS to support Panorama 6.0?
#2

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.


#3

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.


#4

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:


#5

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


#6

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


#7

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”:

DateField[4;3]+DateField[1;3]+DateField[7,-1]

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


#8

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


#9

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.


#10

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?


#11

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.


#12

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


#13

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.


#14

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.