• 1 Post
  • 37 Comments
Joined 1 year ago
cake
Cake day: July 8th, 2023

help-circle
  • android auto

    First I heard of this, but since it seems to be just some software that runs on the hardware of car manufacturers it seems rather unlikely. But very theoretically possible, if the car manufacturer was using default process scheduling in a CPU constrained machine and now switches to real-time scheduling in an update. But that was possible for years before this news, the code has just been mainlined to the default kernel now. If the car manufacturer cared about that they would probably have done it already with a patched kernel.







  • I think the problem might be your PostUp/PostDown lines have an in-interface (-i) but are missing an out-interface (-o) for the forwarding. Try this:

    PostUp   = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE
    PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o ens3 -j MASQUERADE
    





  • It seems like it would be a bit confusing, though, if you had to relearn times whenever you travel somewhere (edit: and dates could flip over in the middle of a work day). But maybe you’d prefer that.

    I’d prefer that over having to change clocks when you travel, and having to have knowledge about the location and possibly having to flip the date when you encounter a reference to a specific time, yes.

    Before they were invented, it was literally just anarchy. People set it to match people they knew. That’s what I was thinking of, but it could also just be one place where noon is at 12:00 PM.

    Yes, you would obviously do the latter. No sense it going back to the bad old days.

    Well, there’s not a round number of second in a day, or days in a year, for example, since they’re all naturally occurring and arbitrary.

    Days in a year ok (except leap years). But seconds in a day are round (discounting days with leap seconds). 24 * 60 * 60 = 86400, which is divisible by two. Did you mean they are not based on the decimal system? I’d be up for a decimal based time system and a reorganised calendar, but that wasn’t the topic of discussion here.

    And then the Earth turns at a subtly non-constant rate, and people have settled on a seven day week.

    Yeah but none of that has much impact on the timezone debate.

    If you do have timezones, it doesn’t make sense to be inflexible with them when they run up against geography or trade and cultural ties, so they’ll be curvy, and geopolitics will itself change over decades and someone will want to change which one they’re in.

    Fair enough. I acknowledged this point in my other post, that there are historical reasons for timezones mostly rooted in administrative requirements. But I don’t think this is a good reason to not adopt a better system per se.

    All of this is a headache if you just want to do a calendar calculation.

    Exactly! So out with the old, in with the new. Sure this will create some other headaches, especially given how deeply rooted some of the relevant nomenclature is in most languages, but the sooner we change this the less it will hurt. I see that it might be a non-starter given the inertia and disunity of globalised society working against it, but it still seems desirable nonetheless, to me at least.



  • And when it does happen it’s usually clarified. In more automated contexts (e.g. a scheduled YouTube premiere) the software converts it automatically - the author inputs the date and time in their own timezone, and viewer sees the converted date and time in their own timezone.

    My point exactly though, this is a whole lot of complexity we could just get rid of by using a single timezone, with the added benefit of that working without any automation or clarification. Next Tuesday 14:00? Same time for everybody, regardless of locality. Everyone will know what part of the solar day that is for them by habit.

    When it does happen it reminds us that the date and time falls on a different time of day for different participants.

    The complexity of coordinating different solar cycles is there either way and unavoidable. So why not use the simpler system?

    Meet me here tomorrow at 01:00

    Yes, semantic drift in these terms would be unavoidable, but I still see the long-term benefits to clarity outweighing the short-term costs in it.


  • We already have that for technology to use - the unix timestamp.

    A unix timestamp is an offset to a UTC date, not a timezone. But fair enough, there is UTC. It’s not used by default however, except by scientists and programmers maybe.

    Maybe I’m missing something. What do you think the benefits would be?

    Removing ambiguity from casual language. Currently when you state a time you are almost always implying your local timezone applies, which might be unknown information to the recipient, especially with written sources like these comments here. With everybody using the same timezone instead you would always make an unambiguous statement about the specific time by default.


  • What would happen on people that live in UTC+12:00 ? When your friend say “lets meet on Tuesday”, which Tuesday it is (because the day changes at noon)?

    Given how +12 is at the front of the “date wave” currently they would probably take it to mean the Monday/Tuesday noon.

    People will resist such majorly inconvenience changes unless the benefit of switching is clear for them. Forcing unpopular changes will guarantee people using unofficial timezone which cause even more confusion down the line.

    Yeah fair. To me the benefit is clear, there is no good rhyme or reason to timezones as a totality, we should come up with a better system. A straightforward approach like using UTC offsets seems best.


  • They just gave an example though of people who made up their own timezone because the official one was bad.

    Yeah, and in reply I argued that they did this out of not wanting to change their habit of associating 12 o’clock with noon. Which is in my opinion an understandable impulse but not a good reason to preserve the status quo.

    These systems exist for people

    Yeah fair, I’m aware I’m toeing unpopular opinion territory here.

    and if no one other than programmers wants to do the internal calculus of “The sun is setting and they’re a quarter of the earths rotation Eastward, so that means they’re probably in bed” every time you want to call someone, then we shouldn’t make the standard that way.

    But the standard is like that right now, worse even with DST and other complexities.

    Right now you just look up the timezone in their profile and send it at 9:00, but without timezones, you need a “database of regional conventions for coordinating business hours”, which is just a worse way of having timezones.

    Well no you need an offset. Like the user has set +8:30 as their offset, so send the notification at 00:30 UTC. That’s not worse than having timezones, that’s having timezones but simpler.

    Timezones exist because they have a purpose.

    Yeah, and some of those purposes are bonkers.

    It’s like abolishing everything except latin1 because Unicode is a pain.

    More like getting everyone to use Unicode, but whatever. Like I said I see why it would be unpopular to the point of being unenforceable, but that doesn’t mean an unambiguous way of communicating time as the default would be entirely undesirable.


  • Well the essay has a lot to discuss, part of which is already (or will be) addressed up and down thread, so towards your TL;DR:

    Yes of course, I’m not suggesting to disrupt circadian rhythms. And yes, lookup tables for solar days will always be required, but I would argue this is an inherent complexity to how we measure time in relation to our behavioural patterns and environment. However doing that by using variously large timezones that do not quite match solar days at their edges anyway, with a lot of them changing their offsets by an hour for half the year, and some of them using half-hour offsets throughout the year, that is complexity added for administrative reasons which are partly obsolete and largely irrelevant to the question off what would benefit humanity as a whole the most.

    If everybody were to use one single timezone you would memorise your relative offset to noon/midnight pretty fast. Like it’s one number to remember, e.g. where you are 4:40am is noon, 4:40pm is midnight, your offset is -7:20. Having those times be (roughly) 12 (for half the year) is just tradition and something we have every child learn. We could teach them about solar offsets just as well. It’s not even really more complex, arguably much less so since you remove the need to confuse them with the chaos that global timezones have grown to be historically.


  • Oh don’t get me wrong, I see how it makes sense. I’m just saying that 1) it is arbitrary nonetheless and 2) it doesn’t outweigh the benefits that could be gained by using a single global timezone. Incidence angle of solar radiation is hardly something most people need or even want to track beyond a certain degree (dawn, noon, dusk, midnight), and the times that would coincide with at your latitude and longitude can be easily learned.


  • people has this urge to associate 12pm to noon and 12am to midnight

    Yeah but that is exactly what I mean with habitual. It’s a learned association of questionable utility. It can be unlearned and replaced with 0400 is noon or 1600 is noon based on your longitude just as well. Dawn and dusk are dependent on latitude and have to be learned for anything not smack-dab on the equator anyway.

    I can see why that would be inconvenient to people, but I would maintain that is only so due to them clinging to a habit.