Usage Download date format is inconsistent in latest download

[Wayno]

I generally download my electricity usage data once a week and process it along with my Solar data in an Excel Spreadsheet. Unfortunately, the date format within today's download is all over the place. Mostly it's the usual format but later data has mm/dd/yyyy instead of dd/mm/yyyy. Time format changes also from hh:mm:ss (24 hr) to hh:mm:ss AM/PM (12 hr format). Then the time format changes back to 24 hour format but date format remains as mm/dd etc. It's also the first time I've received the .CSV file in a zipped format so seems  somebody at AGL has been changing stuff. Can you please fix the date format back to the consistent dd/mm/yyyy hh:mm:ss (24 hr) for all days.

[-Olgi-]

Hi @Wayno, welcome to AGL Neighbourhood. 

We're aware of this formatting change that has occured. Our support team is investigating what has caused it and working on resolving this issue. I'm sorry for the inconvenience this may have caused. 

Kind Regards,

Olgi

[Wayno]

Ok, thanks. Please let us know when this is resolved!

[CLJ]

I am having the same problem.  I've spent nearly the whole morning trying to convert M/D/YYYY h:mm:ss AM/PM data to D/M/YYYY h:mm:ss.  I've converted the downloaded and unzipped file  from csv to xlsx format, but I can't change those date and time values from General values to the date and time format I want to work with.  Also, as mentioned, there are blocks of data with different formats: very time consuming and VERY frustrating!

[pl]

I have the same problem as well. After downloading usage data in .csv format. Instead of date being in DD/MM/YY format it is in MM/DD/YY format When Excel tries to interpret the date and time it stuffs up and the date and time formats change as you go down the sheet. I tried to clean up the data by converting to different formats but with no success. Very annoying

[-Jenna- · Accepted solution]

Hi pl, thanks for being part of the Neighbourhood.

This is a known issue which our team are investigating and working to fix. We apologise for the inconvenience caused with the delay. If you need us to send you any of the data in the meantime, please get in touch here. 

Kind Regards,

Jenna 

[David_AGL]

@NeilC , this looks to be the same issue you contacted me about recently. Hopefully will be resolved soon.

[Wayno]

I use my last good download prior to the format change with 2 years worth of data and just copy the dates from that exactly one year earlier. I then do a global replace on the copied data changing "/2021" for "/2022". Much easier than trying to reformat all the dates........

[NeilC]

@Wayno @-Olgi-  @-Jenna- @David_AGL 

Surprised that this is solved, the issue / problem has not been resolved.

They cannot even fix the issue that the file has been zipped, but does not even have the .ZIP extension so you cannot even download it without an issue.

There was no pre warning of any change, just like a few years ago when they went and changed the time format from 24 hour to 12 hour AM/PM.

Why don't AGL then just supply the file in the INDUSTRY STANDARD NEM format.

My Distributor SA Power Networks supplies the file to me (normally by 07:00) each day, yet AGL takes up to three days just to present the raw data file on occasions.

People also need to understand that a CSV file is not an Spreadsheet file but is a file that contains Comma Separated Values, which is a text based file.

Yes, spreadsheets can decode a CSV file but so can many other programs including programming languages such as python (which now crashes due to the change in 24 /12 hour format) as its CSV reader expects a constant format.

As to the change to US format for dates even if I use linux with one of the many excellent free Office packages the file is still unusable due to the TIME format issue.

Now as you are using that dates from previous files you need to understand that when we go to Daylight savings time, that AGL only reports for 23hours that DAY and if you use last years date times the Daylight savings time change is not on the same day.

As to the AGL replies the answer is simple.

Go to your backup tapes prior to the INCIDENT and restore the PROCESS that used to work.

After 25 years in the IT industry in creating a CHANGE process the BACK-OUT plan should state something like:

.... After implementation, if after USER testing fails, then existing process will restored from BACKUP that occurred prior to the commencement of this change.

USER testing is not the change owner, implementer or one of the people from the team, but someone that will be effected by the change in their daily activities (ie the CUSTOMER).

The Change Manager is responsible to ensure that ALL PROCESSES occur in the change and the CHANGE OWNER is responsible to report to the Change Manager the success / failure of the change.

The CHANGE MANAGEMENT meeting (normally every weekday but on weekends for some changes) should have met and passed this change which does not appeared to have occurred.

David as the TEAM Leader I would thought that you would have been part of this CHANGE MANAGEMENT process and should have some direct feed in regarding this INCIDENT.

Now someone should have RAISED an INCIDENT in your system to report this, it is not a PROBLEM (which may have been raised) as problems can be raised with no issues.

This is an INCIDENT as it has the ability to AFFECT EVERY AGL CUSTOMER.

Well had my say, let's see now how long it takes to resolve this FAILED or ILLEGAL change now.

Imagine if you were a BANK and no-one could read their accounts or download their statements.

By the way there are a number of people is this NEIGHBOURHOOD which would love to get paid to carry out USER TESTING and assist in helping you to get things right for your customers.

If you read this and like my reply please take the time to click the LIKE button.

Cheers Neil