ETOR probably stands for Estimated Time of Restoration, i.e. the time at which the power will probably go back on again. A quick search of ETOR led me to https://www.torontohydro.com/how-we-restore-power, which explains how ETORs are calculated and even has a nice video on it.
Unix timestamps are a duration¹; they're not in any particular timezone. They're "the number of seconds since midnight 1 Jan 1970, UTC" — but while I've used "UTC" there, you can also equally define it as the number of seconds since 19:00 on 31 Dec 1969 in America/New_York. It's the epoch itself that requires a timezone, not the duration since the epoch.
Interesting fact - it was not midnight in Greenwich at the Unix epoch because the UK Government coincidently ran an experiment with staying on British Summer Time the whole year round from 1968 to 1971.
This lead to one of the hardest to track down bugs I ever encountered (ultimately came down to LocalTime(0, "London") coming out as 01:00 when 00:00 was expected)
I've never thought of it this way, but they're technically correct, imo.
A Unix timestamp doesn't specify a time, it specifies an offset from another time. It makes sense logically, the calculation is `current_time - epoch_time`, and the result of subtracting two times is a duration.
They are however, easily converted into a time: `epoch_time + unix_timestamp`, and logically a time plus a duration produces a time.
If a timestamp is a time, that logic all breaks. Like `epoch_time + today` doesn't really make any sense.
