Invalid date/time for non-US dates?

Dec 4, 2009 at 10:41 AM

I can't seem to get Alpha3 to work work with my UK log files.  PAL runs up until "Memory Percent Committed Bytes In Use", and then I get this error:

Get-Date : Cannot bind parameter 'Date'. Cannot convert value "08/14/2007 15:40:38.659" to type "System.DateTime". Error: "String was not recognized
as a valid DateTime."
At C:\PerfMon\PAL\PAL.ps1:3510 char:22
+     $Date1 = Get-Date <<<<  $($aTime[0]) -format "MM/dd/yyyy HH:mm:ss"
    + CategoryInfo          : InvalidArgument: (:) [Get-Date], ParentContainsErrorRecordException
    + FullyQualifiedErrorId : CannotConvertArgumentNoMessage,Microsoft.PowerShell.Commands.GetDateCommand

 

Oddly though, I can't edit the pal.ps1 file to change MM/dd to dd/MM without it then bombing out elsewhere.  I'm guessing my editor is screwing up the file somewhere

Missing expression after ',' in pipeline element.
At C:\PerfMon\PAL\PAL.ps1:3504 char:23
+     { $Value.ToString("#, <<<< #.########") }
    + CategoryInfo          : ParserError: (:) [], ParseException
    + FullyQualifiedErrorId : MissingExpression

Dec 4, 2009 at 10:49 AM

Regarding the 2nd point, it's odd, but after I edit it the only unexpected change is on line 3386, where the "-" is replaced by "–.

So ignoring that as a code-page glitch in my scabby editor, if I replace all MM/dd with dd/MM, then PAL still breaks, due possibly to more precision than expected?

It looks like my timestamps have extra decimal precision to seconds, but the -format argument seems to imply not?  Bit out of my PS depth here :)

Dec 4, 2009 at 11:04 AM

I'm an idiot.  Ignore the date thing.  The date-order is fine.  It's the .nnn seconds that confuse it I think.

Coordinator
Dec 8, 2009 at 4:05 AM

That section of the code is just doing a date difference to hours, minutes, seconds, etc. and shouldn't matter what locale is used. Where are you seeing .nnn seconds?

Thank you,

Dec 9, 2009 at 10:34 AM

I'm not entirely sure.  I just saw it in the error message.  I'll run some new data and see if I can find the source.  Problem is that there are a lot of sources in that collector.

I ran the logs against my laptop and PAL finishes fine, and creates a bewildering array or results :)

I'm trying it again now against the server, I'm hoping it was me doing something wonky with the Data Collectors...

Sep 27, 2010 at 2:07 AM

I am still seeing a related issue running v2.0.3

If I set "Restrict to a DateTime Range" using the gui it errors with:

"Cannot convert value "24/09/2010 6:00:12 AM" to type "System.DateTime". Error: "String was not recognized as a valid DateTime."

In the script that it generates it incorrectly adds random seconds to the end of the -BeginTime and -EndTime fields.  If I remove the seconds from those values and manually run the powershell script it runs fine. In the GUI there is no place to specify seconds so there must be something in the app that is adding this in and breaking.

 

You can see this behavior by clicking "Restrict to a DateTime Range" then going straight to the Queue tab. The times are listed with :00 seconds at the end. As soon as you go back and choose a date you can see that :06 or another value is added to the time. This then causes the script to crash. From my experiments it always seems to be either 6 or 12 seconds it places in the time field.

I am using English (Australia) locale.

Sep 27, 2010 at 2:10 AM

I just also noticed on the Counter Log tab, when ticking "Restrict to a Datetime Range" the status comes up as "Status: An error occured retrieving time range from counter log using Relog.exe from command line."

This may be related?

Sep 27, 2010 at 3:15 PM

Hi Splark,

I have recently passed a fix for this date range using dd/mm/yyyy to Clint which he is going to look to implement.

I'm also currently looking at issues with some other date formats which are proving a little more tricky to resolve notably Norwegian which uses a comma to separate decimals unfortunately Powershell assumes lists with commas should be split into an array.

"Powershell giveth and Powershell taketh away"

Jon

Coordinator
Sep 29, 2010 at 9:27 AM

I just published PAL v2.0.4 which has the changes that JonnyG added. This means that PAL should work for English-US and English-UK locales.