Zagorath

Aren’t those two the same thing? At least in C-style arrays, which might not be how they’re handled under the hood, but is at least how most languages present it to the programmer.

On my desktop I’ve currently got 4 windows with 101, 103, 17, and 191 tabs. Think it’s about 60 on my phone, and currently only about 30 on my tablet.

If I’m not being explicitly paid to be on call, I’m not ever even having notifications come through to my phone from anything work-related.

The difference is just another nit pick someone will find excuses to argue over

No, it isn’t. The scientific research actually suggests that keeping DST is worse than switching back and forth. I have to admit I find that confusing, since a lot of the specific studies I’ve looked at concentrate on the effects caused by the switchover itself, but the meta-analysis doesn’t mince words:

In summary, the scientific literature strongly argues against the switching between DST and Standard Time and even more so against adopting DST permanently.

To be fair, they did say “and for some a half”.

Though that misses the Kathmandu, Eucla, and Chatham Islands, which are all :45.

Oh, I see. Yeah I suppose it is, now that you point it out. It comes from:

• .gov: the US government
• .nih: the US National Institutes of Health
• .nlm: the National Library of Medicine
• .ncbi: the National Center for Biotechnology Information

But really, I only know it because it’s a very common host that comes up when you’re searching for published research papers. I just see “bunch of Ns .gov” and know it’s reliable.

Yeah you’re absolutely right that it does create a tradeoff. My experience has just been that I’d usually consider it a worthwhile tradeoff. In general, the number of people who have to deal with setting meetings is lower than the number of people who attend meetings, especially when you take into account multinational companies.

And when you’re attending a meeting, you only care about knowing what time it has been scheduled for already. It’s in scheduling that you have to work out when is going to be best for your audience, and I’m of the opinion that the distinction between “what time is this in my time zone and their time zone?” and “where does this time sit in relation to their working day?” is net neutral. With one aspect being a strict positive and the other being a net neutral (in my opinion), I think it still wins out and becomes worthwhile.

I personally would prefer if we all used UTC. My working hours would be 23:00 to 07:00. A Brits working hours would be 09:00 to 17:00, and a New Yorker would work 13:00 to 21:00.

But this does have its own drawbacks. Personally I just think those drawbacks, in the sorts of real-world time-related conversations I’ve had, are less than the drawbacks of dealing with varying time zones.

But yeah, the biggest factor is daylight saving time. Doing away with it is the number one option places that use it should take, regardless of whether one advocates for abolishing time zones or not.

Sorry, I don’t know what you mean.

Not sure what you mean. My position is that daylight saving time should be abolished entirely. You linked an article about a push to move permanently on to daylight saving. I pointed out how that is actually a bad idea.

You add a whole number of hours and for some a half

Or three quarters in a few cases.

And of course there are cases where countries spanning as many as 5 “ideal” time zones (dividing the globe into 24 equal slices) actually use a single time zone.

And then when someone tells you the meeting is at 10:00 am, you have to figure out if they mean your time zone or theirs, and if they mean theirs, you then have to convert that to yours. Oh, but your conversion was wrong because one of you went into or out of daylight saving time between the day when you did the conversion and when the meeting took place.

Dates and times aren’t that hard—honestly!

Video is a lecture about how to think about dates and times, through the lens of a specific open source .NET library designed to aid with applying that thinking. It points out how most languages’ standard libraries really work against you, because they conflate different concepts. For example, an Instant (a specific point in time, globally recognised) and a LocalDateTime (a date and time in a way that is irrespective of your location—for example you might want your alarm to wake you at 8:00 am on weekdays, and still do that if you move to a different time zone), a ZonedDateTime (a date and time tied to a specific location—like if you want to say “the meeting starts at 10:00 am Oslo Time”), and an OffsetDateTime (a date and time tied to a specific UTC offset—which is not necessarily the same as a time zone, because “Oslo Time” is a time zone that doesn’t change, but its UTC offset might change if they go in or out of DST, or if a place decides to change, like how Samoa changed from UTC-11 to UTC+13 in 2011.

These are all subtly different concepts which are useful in different cases, but most libraries force you to use a single poorly-defined “DateTime” class. It’s easier and requires less thought, but is also much more likely to get you into trouble as a result, precisely because of that lack of thought, because it doesn’t let you make a clear distinction about what specifically it is.

His library is great for this, but it’s very worth thinking about what he’s talking about even if you don’t or can’t use it. As he says in wrapping up:

You may be stuck using poor frameworks, but you don’t have to be stuck using poor concepts. You can think of the bigger concepts and represent all the bits without having to write your own framework, without having to do all kinds of stuff, just be really, really clear in all your comments and documentation.

A lot of things that people like are bad and should not be public policy.

Some individuals feeling like they like DST doesn’t counteract its significant health detriments.

Assuming you used UTC as the shared time zone, 00:00 on Saturday would start at what is today 4pm in US Pacific Standard Time. So you’d finish work at 01:00 Saturday.

On the other hand, you wouldn’t resume work until 17:00 on Monday.

So you’re not losing any weekend time.

timezones are absolutely helpful from a logistics and coordination standpoint

They’re a downside from a coordination standpoint. If everyone was on UTC, you could say “the meeting is at 04:00” and everyone, anywhere in the world, will know when the meeting is. In the real world, you have to say “the meeting is at 2pm AEST” and then someone in AEDT will have to think “oh, that’s 3pm for me”, and someone in American EST will have to convert to UTC and then convert to their time. It’s a huge pain.

So what if it will be dark well into morning wake hours in the winter

That’s not something that DST does. It would be something that switching to year-round DST would do, but permanent standard time doesn’t change winter hours at all. It can mean you might have dark mornings (especially early and late summer—after the switch to DST and before the switch back to standard time), depending on how far west you are in your time zone and how far away from the equator you are. That’s the main thing DST does: swap bright mornings for bright afternoons in summer. Which is kinda silly considering it’s done at the time of year when afternoons are already bright for the longest. It’s also very harmful to public health.

that-would-make-daylight-savings-time-permanent

fwiw this is by some metrics even worse than switching back and forth

Garmin is like the Apple of the fitness world. Very much not open source, but broadly privacy-respecting.

And like Apple, the reason they do this is because they don’t make their money from data harvesting, they make it by selling high quality hardware at a premium. And depending on your perspective, either unlike Apple or to a much greater extent than Apple, Garmin pushes their hardware by artificially restricting their software. You can expect to get maybe one year of feature updates on your thousand dollar bike computer or running watch, and a few security updates after that. Some of those limitation might be because of genuine hardware limitations (e.g. my Forerunner 935 not getting Garmin Pay because it lacks an NFC chip), but many are purely because they want you to have as much incentive to upgrade as possible.

Someone should get it added to this git project comparing different open source photo libraries.

The quality of this thread is really reaching a nader.

This page lists and compares a bunch of different options. Just quickly eyeballing it, Nextcloud Photos/Memories (not sure if they’re separate apps from the main Nextcloud you mention), LibrePhotos, Immich, and PiwiGo seem the best options.