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!
Tracking PG&E outages by scraping to a Git repo
11–13 of 13 posts
Re: Tracking PG&E outages by scraping to a Git repo
#12Earlier 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.
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.
Re: Tracking PG&E outages by scraping to a Git repo
#13I had problems with git blocking because I was accessing git too much, can you share how to do the same with some tool like proxycrawl?