Guys, you are epic beyond all expectation. You do realize that this fucks security transactions for a large part of GMT + 1, right? Like major fucks, right? And through your help now we know.. There

AHA! I tried them all. Fun times! It is called the veld, is it not? Must I send you a photo from the Cape Town Fish Market which sadly is in Windhoek. Biltong saves lives

In a capital and it was jacked in Doha and Windhoek. Good data though.

You can try zdump -v /usr/share/zoneinfo.default/Africa/Windhoek To understand what your system thinks is the timezone in Windhoek, on my system the latest lines

It seems that Namibia recently changed the timezone permanently (cfr. https://support.microsoft.com/en-us/help/4074837/time-zone-and-dst-changes-in-windows-for-northern-cyprus-sudan-and-ton , sorry

Hi Alex, Sorry to hear of your problem. I’m in Johannesburg, I’ve included my setting below which may help. Note that I set the region to Apple Europe and the system detects Johannesburg (if it

AFAIK cell phones can determine time accurately via the cell transmission, so they are always accurate. Macs, and iOS devices without cell chips, on the other hand, don’t have that benefit nor a GPS

No worries about disagreements: you're looking at the code and I'm getting the condensed version in your description. Your comment about timing being an issue disturbs me since, ideally, the behavior

This sounds like something for Radar. So far, travelling the well-known world (the oddest being the canary islands), I have had any issues with that. I have been tracking the back-and-forth of the

I’m in the deepest darkest jungles of ferocious downtown Africa at the moment (yeah, science) and if I‘m not smoking crack again, all of my business meetings are jacked up by an hour because

You truly are a Hero! and made an old hacker very happy thank you Bill Pitcher bill@...

Well, dang, I got that wrong. (I “fixed” a typo in the email, forgetting to check that it actually worked.) You can’t use a KeyPath expression like “\WindowController.document.model” in

K, the problem I’ve been working around with the kvoDocumet bs documentObservation = self.observe(\WindowController.document.model) { error "Type of expression is ambiguous without more context”

It’s more or less correct, although I think you’re still making it a bit harder than it needs to be. Here are some inline comments on your window controller: You don’t actually need this. The

Thank you for your help with this! I’ve given it another try and hope some knowledgeable person could check that I’m still not Doing it Wrong ™ Currently WindowController.document still

Steve, I don’t want to disagree with you, but I’m seeing additional pieces of evidence which suggest (to me, at any rate) that this issue is related to timing, not insufficient constraints. I’ll

Setting only edge constraints (top/bottom/leaing/trailing) on the image view will not guarantee "consistent" size. Unlike UILabel, for example, an image view doesn't necessarily have an intrinsic size

I have explicit constraints. I expected consistent behavior and really don't understand why I don't get it. I've tried two cases: (1) UIImageView directly embedded in a (sub)-controller's view. Fully

I think I ran into similar issues in the dim past. If I recall correctly, the image view would resize to accommodate the image size if the image was set before a layout pass, or maintain some fixed

1. For any image which has an intrinsic size larger than the destination UIImageView object, the sizing behavior is the same. Namely, when the picker is dismissed (calling loadData(), the upper left