Zero left padding of hours, request


#1

Is it possible to add support for HH as a time component in timepattern(), superdatstr(), superdatepattern() (other?) time formatting functions to pad hours with a leading zero? hh would be used for non-padded output as it works currently. This would be consistent with the date format components syntax. Having output lined up is very helpful for data checking (will also lobby for allowing font change in database view so you could use elegant fixed width fonts like SF Mono or PragmataPro). The recommended work around from here in forum did not seem to work for me:

(“0”+timepattern(time,“hh:mm:ss”))[-8,-1]

, however this equally as verbose does:

replace(fixedwidthright(timepattern(time,“hh:mm”), 5), " ", “0”)

, bit of a pain just to get a standard time format

Thx!


#2

What results are you getting from this?


#3

My mistake, I must have made an error while testing your solution, yes it does work as you stated. However my point remains, too much work for something that is standard.


#4

I looked into this, and if you use HH as the pattern then Panorama X will pad with a leading space. So you could get a leading zero with this formula:

replace(timepattern(time,"HH:MM:SS")," ","0")

This won’t work if you use am/pm format, though, since it would also replace the space between the time and the am/pm. Then you would have to use the formula Dave suggested.

Padding with a leading space is different than Panorama 6, which did not pad at all in this situation. Since the change to padding with a leading space apparently hasn’t bothered anyone, perhaps it would be reasonable to change it to pad with a leading zero. Then again, it is always possible that some of you may not like that change. I don’t have a strong feeling about it, so if you are interested, please vote below, and you can also share your comments. How would you like time patterns to behave if HH is used in the pattern (this would have no effect on the lower case hh pattern).

  • No padding (same as Panorama 6)
  • Pad with space (current Panorama X behavior)
  • Pad with zero digit

0 voters


#5

I don’t have a strong preference, but do recall wondering for years why datepatterns allowed for leading zeros and timepatterns hadn’t. The tradeoff in adding the extra option is that some old databases would change unexpectedly. Because timepatterns weren’t case sensitive (other than the am/pm option) before, I paid no attention to which case I used therein. I have no present idea wherein my old code would be affected and whether I’d care.

If the status quo were maintained, Dave’s work around could be added to the Help, allowing copy/paste implementation. For am/pm patterns it would be [-11,-1] instead of [-8,-1]. If case sensitive padding were added it would be nice if someone could create and upload a tool to scan databases and identify where affected timepatterns had been used. Ideally someone else, as Jim is mired in his family ICU time warp—prayers to all concerned. I don’t know enough to write a thorough scanner, but suspect one is possible.


#6

I think almost all affected timepatterns could be easily located by using the Full Source option in the Open View dialog, and searching for "HH:MM

In other words, Panorama X already contains the tool you are proposing.


#7

Open View’s search isn’t case sensitive, unless I’m overlooking another option. So it also would find all the hh:mm patterns as false positives. It would be better to find just what the proposal would change, with a case sensitive or regular expression search. Case sensitive options for Open View, and for find/replace within Procedures are on my wish list, albeit not highly.

Open View’s search seems to find everything within one or a few databases, a significant improvement over 6. Searching the libraries as well is educational. But it slowed way down when searching All Databases with too many open at one time. To search all my files with Open View required segmenting my search.

To search over the procedures of LOTS of databases at once I replicated a hack I’d used in Panorama 6 and earlier. I wrote a generic procedure to collect the text of all a database’s procedures into one text file, saved in a designated folder. Then added that procedure to every database I wanted to simultaneously search. TextWrangler lets me quickly search that folder on disk, case sensitive or not, even with regular expressions if desired. But I haven’t figured out how to include non Procedure code in those text files. I probably could load a PanoramaX database with the same information, but the wheel I’d already invented works well enough.


#8

While I already voted for the leading zero, I’d like to suggest a format that is more compatible to Excel formats.

In Excel, these are the time formats:
“h” for hours from 0 to 24
"hh" for hours from 00 to 24
"m" for minutes from 0 to 60
"mm" for minutes from 00 to 60

So there would be no need to care for capitalization.


#9

I made a change to the Open View dialog to allow for setting your search method to either “contains” for non-case sensitive searches or to “matchexact” for case sensitive searches. The dialog is found in the _QuickViewLib.pandb file and I have my version of this file available if you want to replace the existing Panorama X version.

http://www.unseensoft.com/download/_QuickViewLib.zip

Simply unzip this file and replace the existing one in the Panorama application. To do this you would right click (or control click) the Panorama X application in the Finder and choose Show Package Contents from the popup. Once that opens in the Finder choose Contents/Resources and replace the existing _QuickViewLib.pandb file with the new version. You might want to save a copy of the original Panorama X version in case you want to reverse this change. Next time you start Panorama X you will have this new capability with the Open View wizard.

This is only a temporary fix since any new Panorama X update will replace it unless Jim decides my version is worth keeping. Here is what my rendition of the Open View dialog looks like with the new option area highlighted:

image


#10

I agree. using the Excel format is IMHO the best solution. In lieu of that it should be unpadded so the user can most easily add their own space or zero depending on their need.