Tracking PG&E outages by scraping to a Git repo
simonwillison.net
Tracking PG&E outages by scraping to a Git repo
1–10 of 13 posts
Re: Tracking PG&E outages by scraping to a Git repo
#2ETOR 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.
Re: Tracking PG&E outages by scraping to a Git repo
#3Unix time stamps are generally considered to be UTC, but fair to ask of them to clarify. Everyone does their own thing with date time.
Re: Tracking PG&E outages by scraping to a Git repo
#4Unix 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.
Re: Tracking PG&E outages by scraping to a Git repo
#5The 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/
Re: Tracking PG&E outages by scraping to a Git repo
#6Unix 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.
They are time, they just don't encode a place. All Unix boxes should have a nearly identical timestamp, independent of where it is.
Re: Tracking PG&E outages by scraping to a Git repo
#7Unix 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.
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)
Re: Tracking PG&E outages by scraping to a Git repo
#8Earlier quoted context omitted.
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.
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 love when reality pokes holes into clean code and perfectly reasonable assumptions made.
Re: Tracking PG&E outages by scraping to a Git repo
#9Earlier quoted context omitted.
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.
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)
Thank you for this. It is a random bit of trivia that may save the day for someone when debugging in future.
Re: Tracking PG&E outages by scraping to a Git repo
#10Are 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.