• Na let’s keep timezones, there useful for humans who generally want time to mean something, but lets ditch daylight savings time, all it does is make scheduling a massive pain twice a year, and messes up everyone’s sleep cycle. Without it, timezones would just be a fixed offset from another, minimizing trouble.

    • 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.

  • obligatory: https://qntm.org/abolish

    Before I read this article, I also thought it would be a great idea to get rid of timezones entirely and just use UTC for everything. To quote from the link, (please forgive me for being lazy and not formatting it correctly)

    Abolishing time zones brings many benefits, I hope. It also:

    • causes the question “What time is it there?” to be useless/unanswerable
    • necessitates significant changes to the way in which normal people talk about time
    • convolutes timetables, where present
    • means “days” (of the week) are no longer the same as “days”
    • complicates both secular and religious law
    • is a staggering inconvenience for a minimum of five billion people
    • makes it near-impossible to reason about time in other parts of the world
    • does not mean everybody gets up at the same time, goes to work at the same time, or goes to bed at the same time
    • is not simpler.

    As long as humans live in more than one part of the world, solar time is always going to be subjective. Abolishing time zones only exacerbates this problem.

    • Yeah it’s just being angry about the fact that the Earth is rotating ball. Wanting to abolish timezones is different from Flat Earth only be degrees.

      Sure the “what time is it there?” question goes away, but it’s replaced by “what are your business hours?”

      Ultimately it will be daytime in one part of the world while it’s night in another part of the world. That will always cause problems.

    • Eh, I think the article blows the situation out of proportion. Overall you’re still in the same situation as before. Instead you would just be looking up a timetable of sunrises/sunsets, instead of a timezone chart. It ends up mostly reframing the question from “what time is it there?” to “what time of day is it there?”. The real version of “after abolishing time zones” is “google tells me it is before sunrise there. It’s probably best not to call right now.”

      I’ve been using UTC on my own clocks without issue, and the change is not some completely reality-breaking thing - not anymore than DST. From a matter of personal perspective it just shifts what time correlates to what time of day.

      using UTC also simplifies the questions “what times can I call you at?” And “when should we have our call?” since you have the same temporal standard. Even before that, I was scheduling calls with family by stating the call would be at such-and-such time UTC.

      The biggest difference is with when the date changes, and I think that ultimately is the hardest pill to swallow, and that’s even compared to stomaching the sun rising at 2 AM. Having it change from June 5th to June 6th in the middle of a workweek, or even jumping to another month would bother alot of folks in a significant fashion.

      Ultimately it’s just a personal practice. No nation is going to abolish time zones if everyone still uses time zones. I just prefer it for various reasons.

  • Timezones are fine to program around.
    DST is a bit of a pickle to plan around, but can be done just fine by a computer program.

    Historical dates; considering leap years, skipped leap years, and times when leap years weren’t a thing or when humanity just decided we skip a bunch of years; are the bane of all that is good.

  • Timezones are kind of a necessary evil though, because without them then you’d have to check regions (or zones) to see if 1PM in China is the same thing as 1PM in Australia is the same thing as 1PM in Bolivia.

  • Inagine going back hundreds of years to convince everybody in the world to use the same time. “No I know not everybody has a clock, but if you could consider sunrise midday that would make my job in the future much easier.”

    • The reason we have timezones is because of the railroads. Before the railroads came in, every town would have its own time, typically set so noon is the time when the sun is highest in the sky. This really wasn’t a problem, as back then it didn’t really matter that the time was different in every little burg.

      Then the railroads came in. They needed things running on a coordinated time table out of necessity, and having every town with its own time was unworkable. I’m sure the railroads would have loved running everything off of the same clock everywhere because that would be simple. But people were too used to noon being the middle of the day, so instead we got the compromise of having timezones so that the railroads can still run on a coordinated time table, but also so that noon is still approximately the middle of the day as people were used to.

      So the solution is just go back to the 1800’s and convince the railroads that timezones are actually silly and that they really should run everything based upon UTC. And if people want rail service to their town, they can just deal with not having 12PM being when the sun is highest in the sky.

  • Aren’t time zones quite straightforward? You add a whole number of hours and for some a half. Compare that to a sundial on the one side and having times that don’t match your day at all on the other, I’d say it’s good

    • 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.

      • But what is the alternative? Sure, fck daylight saving. Having the date changed at noon is fucked up, too, and that’s what happens if you agree to one global time. And having countries that are too big for a time zone is fucked up as well. Russia for example actually only spans to the Ural mountains, everything to the east are colonies. Fuck states in general #nobordersnonations

        • 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.

    • Not if the place doesn’t do daylight savings time, and not all places in a timezone will do that (least in North America) so you need extra code if they do or do not. It becomes a pain after awhile when you do it in multiple projects. Technically one extra setting but it’s still a pain to make sure it’s handle properly in all cases, especially when the previous programmer decided to handle it for each case individually, but that’s a different issue.

      Also when you deal with the times, say in .Net you gotta make sure it’s the proper kind of date otherwise it decides it’s a local system date and will change it to system local when run. Sure it’s all handled but there are many easy mistakes to make when working with time.

      I probably didn’t even get to the real reason, I sort of picked this up on my own.

  •  Zagorath   ( @Zagorath@aussie.zone ) 
    link
    fedilink
    English
    8
    edit-2
    5 days ago

    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.

  • IMO, the biggest problem with timezones is that the people who initially created them were fairly short sighted.

    That and there have been way too many changes to who lives in what timezone. The one that boggles my mind is that apparently there’s a country in two timezones, not like, split down the middle or anything, but two active timezones across the entire country depending on which culture you’re a part of, or something. It’s wild.

    I still don’t know if there’s any difference between GMT and UTC. I couldn’t find one. They both have the same time, same offset (+0), and represent the same time zone area.

    I use UTC because I’m in tech, and I can’t stand time formats, so I exclusively use ISO 8601, with a 24 hour clock. Usually in my local time zone, via UTC. We have DST here which I’m not a fan of, but I have to abide by because everyone else does.

    My biggest issues with time and timezones is that everyone uses different standards. It drives me nuts when software doesn’t let me set the standard for how the time and date is displayed, and doesn’t follow the system settings. It’s more common in web apps, but it happens a lot. I put in a lot of effort to try to get everything displaying in a standard format then some crudely written website is just mm/dd/yy with 12h clock and no timezone info, and there’s nothing you can do about it.

    • I know people who actively fight me on ISO 8601. They don’t like the way it sorts their files/folders, reliant on whatever behavior the operating system does. Whenever data recovery happens or their files are moved, all the change times are blown out the window and the sorting they expect is blown away.

      I’m not yet using a 24-hour clock. But it has me thinking. That’s not such a bad transition for 24-hour local time into UTC. Or just using both. At some point the inconvenience of the local will become vestigial and UTC is what remains.

  • The notifications in one of our systems is aligned with UTC because it needs to be for a whole bunch of background services to function. Periodically (every couple of years) someone raises a ticket to complain that the time of their notifications is an hour out, and the 2nd line support worker will think “well that’s easy, I’ll just change the server time to BST”. This then brings this whole suite of applications to a crashing halt as everything fails.