Issue with new DateTimeOffset::Parse logic in Test-AccessToken (and others)

[thedivinehairband]

When using the 1.5.0 version of the code the new logic to check the bearer token expiry in Test-AccessToken is returning an error:

Test-AccessToken : Exception calling "Parse" with "3" argument(s): "String was not recognized as a valid DateTime." At C:\Users\<USERNAME>\Documents\WindowsPowerShell\Modules\IntuneWin32App\1.5.0\Private\Invoke-MSGraphOperation.ps1:110 char:19 if (-not (Test-AccessToken)) { ~~~~~~~~~~~~~~~~ CategoryInfo : NotSpecified: (:) [Test-AccessToken], MethodInvocationException FullyQualifiedErrorId : FormatException,Test-AccessToken

The line in question is:

$ExpiresOnUTC = [DateTimeOffset]::Parse($Global:AccessToken.ExpiresOn.ToString(), [System.Globalization.CultureInfo]::InvariantCulture, System.Globalization.DateTimeStyles]::AssumeUniversal).ToUniversalTime()

Seems to have an issue with the first arguement

Changing it to the below:
$ExpiresOnUTC = [DateTimeOffset]::Parse($Global:AccessToken.ExpiresOn.ToString()).ToUniversalTime()

Seems to fix the issue, but my knowledge is lacking to be able to tell if this is a good fix or a bodge fix.

Similar logic is found in the Invoke-AzureStorageBlobUpload function and possibly others. Has failed under PowerShell 5 on both Server 2016 and Windows 11 based machines running on UK time format.

[Neon-R1Ft]

Hi,

I installed the module this afternoon but had an issue uploading apps.
I am in the UK
I think this issue will not affect US users.

These are the changes I made and was able to get it to work OK.
I haven't done much testing yet though.

I think these are the only problematic 2 files, couldn't see any others with a problem.

Neon-R1Ft@96643be

[dancing-groot]

Thanks @Ath-PS , that fixed it for me as well! I'm also in the UK, and until today I was on version 1.4.4

[mvanlaar]

Problem is also in NL. The fix from @Ath-PS works for me also.

[thedivinehairband]

The @Ath-PS fix is working for me too. Thanks very much.

[tjgruber]

Ath-PS@96643be

Hi @Ath-PS,
Can you add this fix as a PR? I have tested it both locally (US-based) and in GitHub actions. This is the best fix so that it works consistently globally and is an important one to get in here ASAP (@NickolajA).

[AlkHacNar]

Fix works on German Server too v1.5.0

[MiddleCambium]

Same, also in the UK.

Updating the Test-AccessToken and Invoke-AzureStorageBlobUpload functions as described by @Ath-PS worked perfectly. Nice work!

[SOELMDK]

I'm not sure about the decision about the parsing, but is guess it is there for a reason, so this could also be a fix:

$ExpiresOnUTC = [DateTimeOffset]::Parse([DateTimeOffset]::new($Global:AccessToken.ExpiresOn.ToUniversalTime()), [System.Globalization.CultureInfo]::InvariantCulture, [System.Globalization.DateTimeStyles]::AssumeUniversal)

[johnmessinger]

Applied the fixes above from @Ath-PS (thank you!) but now Invoke-MSGraphOperation seems to throw an exception when calling Test-AccessToken:

Test-AccessToken: C:\Users\***\Documents\PowerShell\Modules\IntuneWin32App\1.5.0\Private\Invoke-MSGraphOperation.ps1:110:19
Line |
 110 |          if (-not (Test-AccessToken)) {
     |                    ~~~~~~~~~~~~~~~~
     | Exception calling "Parse" with "3" argument(s): "String '17/02/2026 11:53:19 PM' was not recognized as a valid DateTime."

Running in PowerShell 7.5.4 on Windows 11. If I've missed something here, appreciate any pointers in the right direction, as I'm scratching my head on this one. TIA.

[AlkHacNar]

@johnmessinger you need to do the fix in both files

[johnmessinger]

@johnmessinger you need to do the fix in both files

Thanks @AlkHacNar, I did update both the Public/Test-AccessToken.ps1 and Private/Invoke-AzureStorageBlobUpload.ps1 files as per the changes suggested.

Seems to be happy after a reboot - go figure :)

Thanks again, this is a great toolkit.

[manelrodero]

I just came across this issue after seeing for myself the problem with the Team Culture (en-US vs es-ES) when checking the dates.

I have tried to solve it from outside the module, in my script like this:

$Global:AccessToken.ExpiresOn = [DateTimeOffset]::ParseExact( 
(Get-Date $Global:AccessToken.ExpiresOn -Format "MM/dd/yyyy HH:mm:ss"), 
"MM/dd/yyyy HH:mm:ss", 
$null
)

But since the module does things again with the dates, there is no other remedy than patching it as you indicate (I haven't tried it yet but I think that, if it works for other languages, it should work for es-ES).

While I'm looking for some time to test, a question for the developers: won't this be included in the official module soon? More than anything because you have to patch each one individually...

Thank you.

[TimGTN]

Hi guys, I just came across the same issue. It's caused by the system's current culture (FR in my case).

It can be easily fixed by adding an ISO date format to the ToString() method:

$ExpiresOnUTC = [DateTimeOffset]::Parse(
    $Global:AccessToken.ExpiresOn.ToString("s"), # Fixed here
    [System.Globalization.CultureInfo]::InvariantCulture, 
    [System.Globalization.DateTimeStyles]::AssumeUniversal
).ToUniversalTime()