Discovery Pattern Extension change date format from YYYY-MM-DD to DD-MM-YYYY

[Owais3]

Hello all,

I've extended a windows os - servers pattern to pull the InstallDate from a server; I'm not using a custom field but using the ootb install_date field that is avaiable on the form.

I've managed to get part of it working but my install_date field does not populate with the date on the ci.

My WMI Query is set like this:

 

And for the Parse Variable the settings are set to this:

This is the output:

I believe it's not setting the date on the install_date field on the ci because the ci install_date format is in DD-MM-YYYY HH:MM and not YYYYMMDD like above.

Any idea how I can convert this to DD-MM-YYYY and set it on the install_date field on the ci upon discovery.

I was pointed towards 'Set Parameter Value' step and use EVAL( as shown below:

But not entirely sure what to put in here to pull the variable from the step before and convert the date and then set it as well.

Any suggestions or any idea how I can get this fully working would be much appriciated.

Thank you

[Owais3]

Hey @doug_schulze 

Thank you for this, worked like a charm and I managed to get the install_date field populated. Thanks for introducing me to the "systeminfo".

I was playing around with it so I could get the time populated (might as well if I'm getting the date right), so I've got it set as following.

When I run the test, it shows the date and time parsed correctly as shown above.

But for some reason the time doesn't get populated on to the field on the ci form, would you know why this would be as it's parsing correctly and the date is working?

Thank you

[SiD2]

Hi @Owais3 

See the install_date field is of type Date/Time and not a string if you see in dictionary record, hence you can't expect this to be populated in the actual CI unless set with that type.

It works in the Pattern Debugger bcoz here everything is just a string and not final values.

Fortunately seems the date format matched hence you could see that in CI but not the time. With your old approach even its in a total different format hence nothing reflected.

It boils down again now to use the GlideDateTime APIs to convert the string value to that type and assign it back to the field in pre sensor script.

[doug_schulze]

Im not really sure as when I lab'd this up it populated the date and time fields as expected on the computer record. I didn't have any interaction with any pre/post processing scripts that needed to use the glideDatetime api that Sid2 mentions in his reply. The proverbial 'works on my machine' 🙂

Perhaps it could be different OS's that we are testing against and the values return just a little differently? I was able to grab the AM/PM to fill in as well that could be the missing key.

But when it comes down to it while you want it to work exactly, how valuable is the time the OS was installed really?

[Owais3]

Hey @doug_schulze 

You are correct in saying that the date and time get's populated as I've seen another post where it has worked.

Now that you mentioned AM/PM, the other post which I am referring to also had the AM in their 'Output' when using the 'systeminfo' command. The machine's I've ran discovery on are Windows Servers.

Did you have to do anything additional to get the AM/PM or was that pulled when you ran the 'systeminfo' command? Because in my case AM/PM is not shown for any of the info regarding Date/Time.

Atm it is not required but I thought if it works and it's there then it's a nice finishing touch to have the Date/Time displayed.

I have two option when and if it comes to that, either try Sid2 way or create a new 'String' field on the form to display Date/Time.

Thanks

[SiD2]

Hi @Owais3 

Yes, you can proceed for now with a custom string field to display as is from the command or else reg the AM/PM I would suggest to change date format from 24hr format or 12hr format on your server.

I could see the same command showing me AM/PM in my win machine.