Get-VBRjob Schedule options date formatting

[Cragdoo]

Hello

One of my colleagues was working on a script, when noticed a mistake or bug with the date formatting for

Code: Select all

(Get-VBRJob).Scheduleoptions

output

Code: Select all

NextRun                               : 01/06/2020 20:00:00
LatestRunLocal                        : 05/01/2020 20:00:04
LatestRecheckLocal                    : 01/01/0001 00:00:00

The NextRun date format appears to be in format

MM/DD/YYYY

but the LatestRunLocal is in the format

DD/MM/YYYY

So when running scripts using these values, you need to be aware of the switch in format.

Is this intentional/mistake/bug?

[jhoughes]

That's interesting, I don't see the same results:

Code: Select all

(Get-VBRJob -Name DomainControllers).ScheduleOptions

StartDateTimeLocal                    : 1/7/2020 12:01:00
EndDateTimeLocal                      : 1/7/2020 12:25:14
LatestRunLocal                        : 1/7/2020 20:25:19

I wonder if it is tied to the regional options of your OS, but it seems odd that only one of the datetime properties has incorrect formatting.

[chris.arceneaux]

Hi Craig,

I was able to confirm Joe's suspicion that LatestRunLocal is using the Windows OS Regional format setting.

I'm unaware if this is by design or not so I've submitted this for internal review. As a fellow coder, it's just add an extra step for us.

Good news, though! These items are PowerShell DateTime objects. As such, you can use the formatting below as a simple workaround:

Code: Select all

((Get-VBRJob).Scheduleoptions)[0].LatestRunLocal.ToString("M/d/yyyy hh:mm:ss tt")

Sample output:

[tsightler]

The reason for the display behavior is simple to explain, NextRun is a property of type "string", while the others are properties of type "datetime". By default, Powershell converts datetime properties into localized time/date when output because you really wouldn't want to see the datetime value itself, which would make no sense to anyone. From a code perspective, there is nothing handle in general because you would use standard datetime handling which isn't impacted by locale.

As to why NextRun is type string vs the others being datetime, I believe that this is mostly historical reasons as the NextRun property has been around in Veeam Powershell for as long as I can remember.

[meelisn]

when I ask next run time for job, I get back string containing date. How can I get that date as date?

Code: Select all

$job = Get-VBRJob -Name 'BackupJob'
$jobSchedule = Get-VBRJobScheduleOptions -Job $job
$jobSchedule.NextRun.GetType()

or

Code: Select all

$job = Get-VBRJob -Name 'BackupJob'
$job.ScheduleOptions.NextRun.GetType()

The problem is that in different servers, different locale information is used to render date to string. And it is unclear which locale (and why that one) is used.

[chris.arceneaux]

Hi Meelis!

Here's an already existing thread considering this topic:

powershell-f26/get-vbrjob-schedule-opti ... 63949.html

[Natalia Lupacheva]

Hi Meelis,

Chris is right, moved your post to the existing thread.
I believe this formatting is what you are looking for.

Thanks!

[meelisn]

I am looking for [DateTime] datatype. That allows me to use date info without guessing the locale. Right now I can't convert string back to datetime because i don't know, which locale was used when that string was created. It is not connected to system locale (Get-WinSystemLocale) or the user locale (Get-Culture). And in different server, the different locale has been used. I would like to get back consistent result.

[chris.arceneaux]

This should get you what you're looking for:

Code: Select all

$job = Get-VBRJob -Name 'BackupJob'
$schedule = Get-VBRJobScheduleOptions -Job $job
$format = (Get-Culture).DateTimeFormat
$datetime = [datetime]::parseexact($schedule.NextRun, "$($format.ShortDatePattern) $($format.LongTimePattern)", $null)
$datetime.ToString()

Sample output:



If this does not provide you what you need, please provide examples and/or screenshots so we can better understand the issue.

Thanks,
Chris

[meelisn]

No. The problem is that I don't know what locale (culture) was used to create the string. And in several servers (out of ~50) that locale is different (and not the one returned by Get-Culture cmdlet.). I need consistent method to ensure that I can discover that locale, or even better, get that date in [datetime] format (and skip that conversion).

From the example above, the date string '10/8/2020' can be both August 10 or October 8, depending which locale is used.

By the way,

Code: Select all

(Get-VBREPJob -Name myJob).NextRun

returns datetime.

[meelisn]

specific example:

Code: Select all

PS C:\Users\kalevipoegD> $job = Get-VBRJob -Name kc007w16*
$schedule = Get-VBRJobScheduleOptions -Job $job
$schedule.nextrun
[datetime]::Parse($schedule.nextrun)
[datetime]::Parse($schedule.nextrun, [cultureinfo]'en-us')
(Get-Culture).Name
(Get-WinSystemLocale).Name

10/09/2020 20:00:00

neljapäev, 10. september 2020 20:00:00
reede, 9. oktoober 2020 20:00:00

et-EE
et-EE

and the date above is actually October 9

So how can I convert that string back to correct datetime? From where can i get the locale that PSSnapin uses to convert that NextRun to string?

[chris.arceneaux]

Hi Meelis,

Here's a workaround using an undocumented API call. As such, it's subject to change in a future version of the product.

Code: Select all

$job = Get-VBRJob -Name 'BackupJob'
$state = [Veeam.Backup.Core.CJobState]::Get($job.Id.Guid)
$state.NextRunTimeLocal
$state.NextRunTimeLocal.GetType()

@veremin - Can we add this as a Feature Request? It's preferred the NextRun metric be returned as a DateTime object vs a String.

[meelisn]

@veremin - Can we add this as a Feature Request? It's preferred the NextRun metric be returned as a DateTime object vs a String.

Yes please, if possible. That would take away all that guesswork ...

[oleg.feoktistov]

It's definitely a why-not. Noted as a FR. Thanks!

[meelisn]

Here's a workaround using an undocumented API call. As such, it's subject to change in a future version of the product.

Code: Select all

$job = Get-VBRJob -Name 'BackupJob'
$state = [Veeam.Backup.Core.CJobState]::Get($job.Id.Guid)

Which versions support that code? on Veeam B&R v9.5, I get the following error message:
Method invocation failed because [Veeam.Backup.Core.CJobState] does not contain a method named 'Get'.

Meelis

[chris.arceneaux]

This was tested using the current version of our product, version 10.