Yes and no. If you are trying to analyse solar data, outside of emonCMS, captured in Australia, you need to know the local time it was collected so you need the timestamp and TZ (which is why ISO 8601 strings are better in this case).
And I am not suggesting otherwise. The calculations are always done relative to UTC as at that point the TZ is irrelevant. However, when comparing data, it may need to be compared relative to the local time it was collected - so compare the amount of solar energy captured either side of midday in 2 different locations (and TZs).
Are you suggesting you accumulate more than one feed? If so then yes that needs to be accounted for, but if accumulating a single fed, at that point, the TZ is irrelevant.
I have already said (twice) you can’t and that is an outlying case that would need to be handled.
One way to handle it is to convert each displayed feed so it corresponded to the scale and externally decide if the scale is user TZ, browser TZ, a specified feed TZ or a completely different TZ selected. This is already done for the first 2.
We already have 2 TZs in use, browser and user. Trouble is neither are actually related to the Feed TZ - it is assumed the Feed TZ is the same as the user TZ.