SMAT history date stamp format changed in 19.1

[Jeff Dinsmore]

I notice that date stamps on auto-cycled SMAT files has changed from  CCYYmmddHHMMSS to CCYY-mm-dd_HH-MM-SS

This throws a wrench into our SMAT archiving and search scripts.  I suspect it might cause some headaches for others as well.

Is there some functional reason why this change was made?

Is there a way to config 19.x to use the old format instead?

Jeff Dinsmore
Chesapeake Regional Healthcare

Topic

[Cullen Linn]

We have the same issue / concern. Any news from anyone on this?

[Jeff Dinsmore]

No.

I don’t see what benefit there was to changing the file name format, but we just changed the code that finds SMAT files to include the new naming.

Jeff Dinsmore
Chesapeake Regional Healthcare

[Rob Abbott]

We had a few requests to change the date format.  Here’s some detail that I received on this which is why we made the change.

 

Having things in a more normalized format like “CCYY-mm-dd_HH-MM-SS” make sorting in an “ls” nicer and more readable for human eyes.  It’d be great to have any log/lock/revision/smat/archive file with a date extension use the above format for being.  There may be some minor heartburn temporarily, but in the long run it’s better for everyone.

 

Rob Abbott
Cloverleaf Emeritus

[Jeff Dinsmore]

My concern is for the wrench this throws into scripts that work with smat files.

It’s a particular problem if those scripts use an alpha sort to put the files into date/time order. The new format breaks that method.

 

For example:

hcitcl>set fileList

hcitcl>lsort $fileList

jef2020-01-02_23-45-00.idx jef20200102100345.idx jef20200102223018.idx

 

The change in the format causes the list to sort out of order. The newer format file sorts to the front of the list because of the dash after the year, but it ought to sort to the end.

 

Like this:

hcitcl>set fileList

jef20200102100345.idx jef20200102223018.idx jef20200102234500.idx
hcitcl>lsort $fileList
jef20200102100345.idx jef20200102223018.idx jef20200102234500.idx

 

Fortunately, our scripts sort files by mod time, so that’s not an issue, but we still need to support the new format in addition to the old one.

I was looking for files like xyz<CCYYmmddHHMMSS>.msg, for example.

Now, since I’m looking back in my stored SMAT files, I need to support the new datestamps as well.

It’s not that it’s a huge amount of overhead – it’s just aggravating.  I think this was a problem that didn’t need solving.

Jeff Dinsmore
Chesapeake Regional Healthcare

[Cullen Linn]

We have more than one tool that relies on the formatting of the files. While we queue the updates to those for the new format, we’ve had to add a temporary recurring routine that goes through and parses each SMAT file name and creates a symlink to it in the same folder but using the old / previous file name format.

Ideally we’d be able to just supply our desired suffix pattern to Cloverleaf and that would be used when the files are created rather than the suffixes just changing on new Cloverleaf versions. For example, if we could just provide somewhere in the Cloverleaf config that we want a suffix of format <smat base name>_${process}_${site}_%{CCYYMMDDHHMMSS} then Cloverleaf would produce the files named as somethread_myprocess_mysite_20200206064121.smatdb.

[Rob Abbott]

That is a great idea Cullen!  I will take it under advisement for a future release.

Rob Abbott
Cloverleaf Emeritus

[Author]

Replies