Tracking PG&E outages by scraping to a Git repo(simonwillison.net)
simonwillison.net
Tracking PG&E outages by scraping to a Git repo
https://simonwillison.net/2019/Oct/10/pge-outages/
12 comments
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.
The San Francisco Chronicle used the data I scraped in their own visualization here, combining it with wind data: https://projects.sfchronicle.com/2019/wind-outage-map/
Nice. I used this a dozen times over the outage period. Thank you for your work!
Unix time stamps are generally considered to be UTC, but fair to ask of them to clarify. Everyone does their own thing with date time.
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.
¹iiiish. Let's forget leap seconds exist.
¹iiiish. Let's forget leap seconds exist.
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)
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)
Thank you for this. It is a random bit of trivia that may save the day for someone when debugging in future.
I love when reality pokes holes into clean code and perfectly reasonable assumptions made.
They are time, they just don't encode a place. All Unix boxes should have a nearly identical timestamp, independent of where it is.
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.
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.
Are there any data centers in these areas? It would be interesting to tie this information to site outages to see who has proper fail over.