> That's part of why they are tied to a certain city -- time zone rules are unlikely to bisect a city, although if they did I guess they'd have to deprecate it as a timezone name and use something else! Not sure if this has ever happened.
It's actually easier to create this problem than by bisecting a city, and the easier way is even more complex than bisecting a city.
You obviously can't put every hamlet, town and village into tzdb, for a lot of reasons. So, if you're trying to represent a time in a place that isn't in tzdb, you have to pick the nearest location that is in tzdb. And it's quite possible that between when you enter your time and when that time comes to pass, the location you were specifying for changes it's rules in a way that's different from the original place you chose.
If you bisect a city, you could create two new names, so that if you encountered the old name you'd know that something needed to be reconciled. But if you chose the nearest place and then your rules changed, you'd have no way to know automatically that it needed to be revisited.
For example, parts of Chile decided not to do DST any more. To support this, a new timezone, America/Punta_Arenas, was added to tzdb. Before this, if you were in Punta Arenas, you would just put all your times as America/Santiago. And now you have no way of knowing if those times are really supposed to be Santiago or if they were Punta Arenas and Santiago was just the best you could do at the time.
Location-based tz's are the best we can do right now but even still they have intractable problems when things change.
Yep. That said, for end users it's a fairly good story because consumer OSs have gotten very good at automatically adjusting clients' time zone based on geo-location. Just like when you fly to another country and the first thing that happens when you connect your laptop to the internet is you're offered to change your time zone to the local time zone. I assume that the same thing happens when you're in a place whose IANA time zone changes like your America/Punta_Arenas case or many others like it.
On re-read, I understand the other aspects of what you mean better. True!
For dates in the past it isn't much of a problem. `America/[city in chile]` in the past (created before the change, refering to times before the change) still has a specific point-in-time meaning even when things change.
The problem is dates records created in the past but referring to times in the future. Which could now be ambiguous or wrong... and this is the first time I'm thinking about it, I'm not sure how easy it is to detect, I guess it should be detectable which dates may be ambiguous/wrong if you know the date of their creation (before the change was known), but it would take caring to write guards about it and having access to databases with sufficient info.
> For dates in the past it isn't much of a problem. `America/[city in chile]` in the past (created before the change, refering to times before the change) still has a specific point-in-time meaning even when things change.
Right - date-times in the past are always easy (at least until you have to take relativity into account). An event happened at some instant in the universe and you just need an agreed upon representation of that instant. UTC works fine for this - record the UTC-based instant at which the event happened and you can always translate it into any other representation without losing information. Recording it in your local timezone is fine too, as long as you also record the UTC offset or timezone along with the instant.
> I guess it should be detectable which dates may be ambiguous/wrong if you know the date of their creation (before the change was known)
Yeah - in theory, when a timezone is added, you could probably link it to timezones that users of the new timezone might have previously used. And then any future times that were saved using that timezone, you ask someone if they are still correct or if the timezone needs to be adjusted to the new one
For example, if a new timezone was added for southeast Colorado, you might ask someone about all times scheduled in both the Denver & Phoenix timezones, because you don't know which one people might have picked.
It gets complicated though because you need to keep track of which entries have been double checked and which ones haven't, and you need to keep track of the version of tzdb that you reconciled against, because there could be another change in the future.
Right, I mean that if in 2030 for some odd reason half of Punta Arenas does DST and half does not, then 'America/Punta_Arenas' would not work as a timezone designator anymore! Obviously unlikely, I probably should not have mentioned it.
https://github.com/tc39/proposal-canonical-tz - appropriately to these comments, a proposal to handle tzdb changes, built on top of JS Temporal, includes some great examples of all the ways this can happen
> https://github.com/tc39/proposal-canonical-tz - appropriately to these comments, a proposal to handle tzdb changes, built on top of JS Temporal, includes some great examples of all the ways this can happen
Thanks! I was the co-champion of that proposal. Parts of it were merged into Temporal last year, and other parts are already part of the JS Internationalization (ECMA-402) specification here: https://tc39.es/ecma402/#sec-use-of-iana-time-zone-database
I don't recall getting stickers at any clubs NYC, although it's been a few years since I lived there. It was always on the honor system at places like Output and events like Black Market.
Maybe it varied depending on the night, but I remember Output being stricter about it the first few years they were open – staff would regularly confront people who took photos. But that seemed to fall off entirely over their final couple years.
Output was definitely doing stickers for a while, I still have several of them (on a stickerbombed bicycle frame). I can't remember whether that was in the early years or the late years though.
No, factors are supposed to have different qualities, such as:
"Something you know"; "something you have"; "something you do"; "something you are [biometrics]"; "somewhere you are [geolocation]".
Passwords are in your head - "something you know".
TOTP codes are generated by a hardware token - "something you have".
If the TOTP codes are crammed into your password manager, then the factors are no longer distinguished by these qualities, but they're now the same factor, and it's not true MFA anymore, whether or not they're split up across devices, or apps.
Actually, they are pretty much split up. To get access to my passwords and TOTP secrets, the attacker needs one of my devices (something I have) and its password (something I know) or my face/fingerprint (something I am).
The whole point of a fully featured password manager like 1Password or Bitwarden is to rely on it instead of the security of the service you're using. And that implies that you must trust the security of the vault itself.
Of course, each device you have is an additional (an equally dangerous) attack surface. However, most people should be more worried if someone hacks into their devices than their Facebook accounts anyway.
2FA via TOTP implies two things: 1) you know a password; 2) you know the seed. This is why people criticize that approach. In practice, knowing a password and having a file (seed) seem different enough, and work against some phishing threats.
Logging in through a password manager requires that you know a password (your master password), and have a file (your vault).
I think that there are just very few notifications where a summary is the thing I want. Most of them I either don't care about at all or I want to see the actual text. Either it's important and the details matter or it's, like, a text from my wife and I want to read it in her voice and not a summary.
The fun of my family group chat is reading the messages from everyone.
It's still cheaper to not buy a phone. Yes, buying with pre-tax dollars is cheaper than at a store. But not buying one at all is even cheaper.
And business expenses, like a new phone, are usually above the line, meaning you essentially get a discount of your marginal tax rate, you don't just get it for free.
I don't think they meant it like "I have to get the new one for tax reasons", but more like "I get the new one instead of my wife getting the new one, for tax reasons"
Yet if you'd buy normal phones, you'd not be spending a thousand bucks a year but rather something like 4× 300 bucks every 4 years or maybe 4× 500 every 5 years depending on what tier you get (assuming a standard family with 2 parents and 2 kids). Then nobody has hand-me-downs and everyone gets a fun new toy at the same time. You can even pick the model that fits each person's usage best! Some can have a bigger battery, others can have more storage...
Your total expenses are less than half and the average phone age is the same while being adapted to everyone's needs. Each device is about 90% as good as the thousand-buck ones (assuming no one has special requirements, like if you're really into photography then either a camera or a top-of-the-line phone does make sense! Exceptions exist for sure)
Or you tell yourself you can get a discount (omg!) by buying it for business and get yourself a shiny new toy every year :). I know some people that do this indeed
In a family group, at least one person in the hand-me-down chain is going to have a problem with their phone every year, so it makes sense for all the phones to scoot a step down regularly. And yeah, if the person first in line can claim them as a business expense then that’s a good excuse.
Yes of course it still costs money and not worth it if you derive zero benefit. But you pay less money, so you expect over many users there will be several for whom its worth upgrading at the lower price but not the higher price.
Yeah it feels like the ideal way is to feed in a transcript of the announcer audio + some standard stats. That would ensure you catch both the human stories & the factual content.
But I wonder if there are licensing issues with using the audio/transcript to generate your summary. I know that the raw stats are public domain but I wouldn't be surprised if they can't use the transcripts or audio.
It's actually easier to create this problem than by bisecting a city, and the easier way is even more complex than bisecting a city.
You obviously can't put every hamlet, town and village into tzdb, for a lot of reasons. So, if you're trying to represent a time in a place that isn't in tzdb, you have to pick the nearest location that is in tzdb. And it's quite possible that between when you enter your time and when that time comes to pass, the location you were specifying for changes it's rules in a way that's different from the original place you chose.
If you bisect a city, you could create two new names, so that if you encountered the old name you'd know that something needed to be reconciled. But if you chose the nearest place and then your rules changed, you'd have no way to know automatically that it needed to be revisited.
For example, parts of Chile decided not to do DST any more. To support this, a new timezone, America/Punta_Arenas, was added to tzdb. Before this, if you were in Punta Arenas, you would just put all your times as America/Santiago. And now you have no way of knowing if those times are really supposed to be Santiago or if they were Punta Arenas and Santiago was just the best you could do at the time.
Location-based tz's are the best we can do right now but even still they have intractable problems when things change.