steeznson,

The UK press every year makes a huge song and dance in opinion pieces about getting rid of DST. However I’m always horrified to see that people want us to keep British Summer Time instead of Grenwich Mean Time. I understand that there are “longer evenings” in BST; however we literally invented GMT and coerced the rest of the world to adjust their times based on that. From the point of view of being constantly compatible with UTC and having more consistent business hours for international companies it makes more sense to me if we kept GMT.

Also the longer evenings thing can be achieved by simply staying up an hour later. It’s not exactly like an hour is being stolen from you when the times switch, the change of clocks are mainly pointless admin.

Lastly I read an article recently that described a correlation between the incidence of heart attacks and the clocks changing. The theory is that just slightly messing with people’s sleeping patterns can cause additional strain on the body.

somethingp,

No the longer evenings are achieved by work starting and ending an hour earlier. And it’s literally easier to change the time zone than to change corporate culture.

steeznson, (edited )

So would you be team BST if we had to pick one? I’m just personally not sure it’s such a loss when the sun is out until 10pm at the height of summer.

Edit: to be honest that would probably be my 2nd preference. Anything except the system we have now where the clocks change!

somethingp,

I think I want work to end an hour earlier in the winter because of how early the sun sets, and care much less about the summer. So however it’s done, it would be great if office jobs could happen when it’s dark outside and we could live our lives during daylight.

steeznson,

Mmm yeah I’ve noticed that my retired parents keep telling me what a great summer we’re having every year and I’m completely unaware of it due to being cooped up inside.

AngryCommieKender,

Another point for GMT, in the mid '70s, the US went onto DST year round for a couple years. People hated it so much they changed back to switching the time.

If we wanna do away with DST and BST, we need to go back to standard time, as the later sunset in the summer translates to no sunlight for workers in the winter

perviouslyiner,

The only downside of being in GMT is that programmers here almost never notice their timezone bugs when developing systems in the winter.

Still, avoiding a whole other class of bugs would be nice.

dullbananas,
@dullbananas@lemmy.ca avatar
JayDee, (edited )

I’ve just said ‘fuck it’ and switched all my clocks to UTC. I don’t even care anymore.

uis,

Why not metric time(TAI)?

Quill7513,

Or why not just seconds past the epoch?

uis,

Metric seconds or UTC seconds?

Quill7513,

I’m gonna say SI

nabladabla,

leap second corrected or not?

JayDee,
uis,

Reasons just states difference, but does not answer why.

dukk,

On the other hand, TAI does not take into account the variations in Earth’s rotation speed, which determines the true length of a day. For this reason, UTC is constantly compared to UT1. Before the difference between the two scales reaches 0.9 seconds, a leap second is added to UTC.

On average, Earth has been slowing down a bit over the past decades, so UTC is currently running 37 seconds behind TAI.

uis,

So leap seconds is advantage here?

JayDee,

There’s literally a section titled ‘why use UTC - not TAI?’.

perviouslyiner, (edited )

Is that supported in any common operating systems?

uis,

Yes, CLOCK_TAI here

ytg, (edited )

Before timezones and trains, each town had its own natural time (based on the sun or whatever). Would you have preferred that?

vox,
@vox@sopuli.xyz avatar

tbf there are libraries capable of handling that too, like rust’s chrono

arc, (edited )

I once developed an electronic program guide for a cable TV company in New Zealand and I’d lose my mind if I had to use timezones. The basic rule of thumb was:

a) Internally you use UTC religiously. UTC is the same everywhere on Earth, time always goes forward, most languages have classes that represent instants, durations etc. In addition you make damned sure your server time is correct and UTC.

b) You only deal with timezones when presenting something to a user or taking input from a user

Prior to that I had worked for a US trading company that set all their servers to EST and was receiving trades through the system which expressed time & date ambiguously. Just had to assume everywhere that EST was the default but it was just dumb programming and I bet to this day every piece of code they develop has time bugs.

uis, (edited )

time always goes forward

It not always goes and not always forward. I think you need metric time(TAI) instread.

arc, (edited )

UTC always goes forward regardless of the timezone and local time. That is why you should use it. To take my EPG situation above, I stored program start / end times in UTC so they would render properly even if DST kicked in or not during the middle of the program.

uis, (edited )

Ok, this is more unix time quirk that can’t handle 24:00:00 and skipping 23:59:59.

UTC always goes forward regardless of the timezone and local time

But not unix time.

I stored program start / end times in UTC

If your program finishes in less than one seond it might report negative time.

arc,

I didn’t say Unix time, I said UTC. And no it won’t report negative time, not unless somehow the system clock was modified while it was running…

uis, (edited )

not unless somehow the system clock was modified while it was running…

Which is how most systems handle leap seconds.

arc, (edited )

Leap seconds still make time go forwards, not backwards. NTP clients would also resolve small time discrepancies while still advancing forwards prior to the next time sync.

uis, (edited )

Leap seconds can make time go both ways, but adding them makes time stop/go back because 24:00:00 cannot be represented as 1/86400 part of day N instead of day N+1 on major OSes. And they were only added so far.

arc, (edited )

It doesn’t work like that. UTC goes forward always. Leap seconds are scheduled and known in advance. NTP time services will just smear time advancement a little to account for an additional second. Time never has to go backwards. This is how Google does it.

uis,

This is how Google does it in their datacenters, but not major OSes by default

letsgo,

Standardising on EST is fine; it’s just UTC plus a constant. If they flipped between EST and EDT, now that’d be insane.

arc,

Yes as long as the rules are known, but it’s really just better to do things sanely and leave no margin of doubt.

loutr,
@loutr@sh.itjust.works avatar

Yep, case in point flipping between EST and EDT may be “insane” but that’s the default for systemd-timesyncd. So now you have to be 100% certain that it’s disabled on your servers, and on the remote hosts interacting with them.

BeardedGingerWonder,

Best I’ve seen is a process scheduled on UK local time (including hour changes) running on a server that maintains Eastern local (including hour changes) but the process logs in EST ( and does not move with the hour)

jabjoe,
@jabjoe@feddit.uk avatar

The only code with timezones should be the bit squishy meat bags touch. Everything’s is should be UNIX time. Or it you are unfortunate enough to be on Windows, NT time.

Some unfortunate programmers already have to deal with the speed of time not being a constant. In a distant future, timestamps might always have a universal position (and speed), and is that much different from timezones?

Or we find some way of removing time distortion of physics. Find the universe’s real systick. 😃

Zannsolo,

No UTC. Convert/use UTC on the way in and covert to local time for the user or local time of the noun the date is for in the display.

jabjoe,
@jabjoe@feddit.uk avatar

Any UTC type is going to do native time and convert for display.

But with native time directly, you can just an int64 with loads of space for fine resolution via multiplication.

Storing time broken up into separate units is crazy.

corsicanguppy,

I feel you’re conflating TimeZones with ever-changing Daylight Savings time rules.

arc,

True but so do most computers. Computers have a database of timezones and time offsets around the world. Depending on the UTC date and time, and your current timezone it will look up what offset to apply to show the local time. The database is very gnarly since rules change over time, e.g. maybe in the 70s some countries had longer DST to counteract oil shortages.

Immersive_Matthew,

I would have stern words with John Riccitiello the ex Unity CEO who really neglected the core of their business for the years he was there. He was fired not too long ago. Games from scratch covered the conclusion of that train wreck. The new CEO seems to get that they need to refocus on the engine and making it better for developers versus chasing money. youtu.be/woTLLrgywwE?si=BIXTJGGMjpjv72vO

technojamin,

I used to feel this way. Over the course of building out 2 calendar systems in my career (so far) and having to learn the intricacies of date and time-related data types and how they interact with time zones, I don’t have much disdain for time zones. I’d suggest for anyone who feels the same way as this meme read So You Want To Abolish Time Zones.

Also, programmers tend to get frustrated with time zones when they run into bugs around time zone conversion. This is almost always due to the code being written in a way that disregards the existence of times zones until it’s needed and then tacks on the time zone handling as an afterthought.

If any code that deals with time takes the full complexities of time zones into account from the get-go (which isn’t that hard to do), then it’s pretty straightforward to manage.

sacredfire,

Time zones are part of it, but also daylight savings is a real pain in the ass. And like you said it gets particularly complicated when you’re dealing with a system that deals with these things as an afterthought, which seems to be a lot of older libraries for time. For instance, the Java date utils are a nightmare and are now considered semi deprecated replaced by a new java.time api. That is, of course, no help for the ridiculous amount of things that depend on these stupid date utils and no one wants to spend the dev hours to refactor.

seth,

I agree with you. Every language I’ve used in the past 15 years has a datetime library or at least standard cookiecutter functions available for conversions, calculations, and adjustments for leap years and daylight savings. Store everything as a datetime in a ISO format with TZ offset or a Zulu indicator, and just convert on the client end if you need to, with a toggle for UTC/local and an option to choose your preferred local.

If you have some exotic or fuzzy edge case requirement like alternative calendar systems or dates before and after the Julian - Gregorian changeover, the wheel has already been invented and there’s a decade-old stackoverflow thread discussing it ad nauseum, with a 200+ point answer that gets updated every couple years as new tools or major updates become available.

Maltese_Liquor,

This did little to convince me that timezones are an unnecessary construct. Pretty much every point made was done from the perspective of someone who had already decided their opinion rather than objectively weighing the pros and cons.

Lifter,

I agree. It’s written like “ugh I’m used to timezones, now what?”.

t_veor,

Yeah, the article is written like it’s parodying those who want to abolish timezones, but I’d be interested in specifically what you found unconvincing? I read the main point as being that time zones are an arbitrary social convention but that that arbitrary social conventions are pretty useful for humans.

Like one thing that the article does is repeatedly asking the question “but what time is it in Melbourne?” which I guess sounds pretty silly if you think timezones are unnecessary, since the question would be meaningless if timezones were abolished, and people in different parts of the world would already have centered their day around their respective parts of the clock and you would just look up what the times for everything are in another place. But I think the author was kind of already discarding that idea, because it’s just equivalent to timezones - you have a lookup table for each part of the world to find out what people do at a certain time, except instead of being a single offset you have like a list of times like “school openings”, “typical work hours”, “typical waking hours” (?) etc. This system is basically timezones but harder to use for humans. So the author asking “but what time is it in Melbourne?” is in the context of this table not actually existing, because if it did, then you haven’t actually abolished time zones.

BeardedGingerWonder,

I disagree about the table - if you’re interacting regularly across timezones you tend to convert everything to your local time anyway - India’s on lunch at 9am, US is starting at 14:00, because that’s how it fits into your day.

Carighan, (edited )
@Carighan@lemmy.world avatar

Yeah but also if we’re being honest, from a programmer perspective the timezone has no bearing on what you do, and is hence not a problem at all.

After all, much like you translate the language of your UI when displaying in X, you also add Y hours to all times shown in X. Done. You wouldn’t even need to persist the zoned time data anywhere, given their static nature you could decide the final timestamp shown at display time, purely on a client, visual, level.

OTOH, daylight saving time turns itself - and timezones - into an utter mess and whoever invented them hopefully is proud of the raw amount of grief and harm they caused the world. It causes all kinds of issues with persistence, conversion and temporal shifts in displayed time due to the ephemeral nature of the +X minutes added. Or not. That’s the worst part.

So timezones: Fine, it’s just bling bling on display anyways.
DST: Burn it at the stake.

t_veor,

Yeah, I’m in agreement that DST is kinda pointless and could probably be abolished, but the thread is about abolishing timezones in general (or so I thought).

Abolishing DST doesn’t eliminate all the weird issues with “ephemeral” offsets though. Suppose the user wants to set a reminder for a recurring event at 3pm, and then moves to another country. Do you keep reminding them at 3pm in the new time zone or the old time zone? Maybe the reminder was “walk the dog” and the user meant for it to be at 3pm local time, or maybe it was “attend international meeting” and the user meant it to be at 3pm in the original timezone. (This admittedly only happens to calendar apps so isn’t something that most applications have to deal with, unlike displaying timestamps in general.)

But other than that, I’m of the opinion that as programmers we’re supposed to model the problem space as best we can and write software that fits the problem, rather than change the problem to fit our existing solution. After all, software is written to be used by humans, not the other way round (at least not yet). So if DST is something those wacky humans want and use, then a correct program is one which handles them correctly, and a programmers job is to deal with the complexity.

KillingTimeItself,

not a programmer myself, but actually fuck you, UTC was the correct choice, anything that isn’t UTC is a wrong choice, and i will literally fight to my death over this.

Timezones are dumb and stupid, and you cannot convince me otherwise, so far the single best argument i’ve heard is “well actually, the hands on a clock and the numbers themselves roughly represent the cycle of the sun in the sky during the day.” Which is pretty good, until you realize that clocks tend to be circles, and you can often just rotate them. And suddenly, the numbers now match up perfectly. But i’ve also never once heard of someone caring about that specific feature, so uh. Good riddance frankly.

Timezones kind of made sense back in the day, when the sun was the only realistic timing system, and pre internet, when people stayed where they were. But now that people don’t do that, and the internet tends to do this thing where it exists. I refuse to believe it makes more sense to have timezones than not.

“Hmmm yes please, i would like to order the time here, but halfway across the globe please” - statements dreamed up by the utterly insane.

ok that concludes my rant. Now i’m going to go set FUCKING DAYLIGHT SAVINGS TIME on my clock because FOR SOME REASON THE TIME JUST CHANGES HALFWAY THROUGH THE YEAR FUCK YOU.

datelmd5sum,

My man.

KillingTimeItself,

The fact that i even have to think about timezones at all is hilarious to me. Jet lag? UTC would fix that, the time ANYWHERE you are is the time you are normally at, it’s just the day/night cycle that’s bunk. So now instead of being confused as to why things are pretty normal, but you feel utterly shit. You just feel very confused, and probably still tired, but it’s very obvious why.

This shit sends me into schizophrenic ramblings i swear to god PLEASE stop using timezones.

MrRazamataz,
@MrRazamataz@lemmy.razbot.xyz avatar

Don’t think your username checks out, seems like time is killing you

KillingTimeItself,

No. Thats why im killing IT. Because it fucking sucks, and i hate it, and it should die.

Carighan,
@Carighan@lemmy.world avatar

Timezones are dumb and stupid, and you cannot convince me otherwise, so far the single best argument i’ve heard is “well actually, the hands on a clock and the numbers themselves roughly represent the cycle of the sun in the sky during the day.” Which is pretty good, until you realize that clocks tend to be circles, and you can often just rotate them. And suddenly, the numbers now match up perfectly. But i’ve also never once heard of someone caring about that specific feature, so uh. Good riddance frankly.

This is an interesting thought:

If we had UTC before we decided on a lot of modern standards - by whatever means we got it - I wonder whether it would have just evolved that Celts are used to the sun rising at 4-10 on the clock, but an Ainu is entirely used to the sun rising at 13-19.

KillingTimeItself,

if we knew that people would be universally connected across the world, independent from the solar cycle. Than yes, absolutely this would have been considered.

We didn’t know that then, we do know that now, and we also know that when gas pumps in finland experience a leap year, they stop working. It’s literally Y2K but completely random, and entirely jumpscare based. You have no warning.

I mean i live in the midwest, in the summer i’m used to the sun setting at like 10pm. In the winter it sets at like 5-6pm.

t_veor,

I know I’m probably not changing your mind on this but interested in how you would want the system to be? Regarding your point about being able to rotate the clock so it matches the local solar cycle, suppose we’re in a place where we have 13, at the top of the clock, because that’s when midnight is where we are.

And let’s say it’s Wednesday 3rd April today. What happens when the clock reaches 13? After 1 second elapses, does your local clock go from Wednesday 3rd April 12:59:59 to…

a) Wednesday 3rd April 13:00:00 b) Thursday 4th April 13:00:00

If a) then you have the problem that the date change is now in the middle of the day, and most of the time you can’t even say “what day is it today”. (If 13:00 is midnight, then 00:00, when the date would roll over, would be just before noon.) You have to say today is "Wednesday/Thursday, or “3rd/4th April” because when you wake up it’s Wednesday, but after lunch it becomes Thursday.

If b) then you have the problem where it may be Thursday 4th April 13:00:00 where you live, but actually it’s not midnight yet somewhere else and so simultaneously it’s Wednesday 3rd April 13:00:00 there. And in fact every location has their own time at which the date rolls over and it’s not even possible to interpret a timestamp unless you have a table that tells you when midnight is for each location.

Maybe you feel that one or both of these are not really big enough of a problem, or maybe you can think of some other way of dealing with this that I haven’t thought of. And yeah, both of these issues sort of happen already with timezones – the issue in a) happens if you stay up past midnight, but at least it always happens at midnight at not when most people are awake and doing their business. The issue in b) sort of happens already since it can be Wednesday in one place and Thursday in another, but at least the timestamp would always indicate how many hours past the date rollover it is.

MisterFrog,
@MisterFrog@lemmy.world avatar

Thank you! Drives me up the wall that when people suggest this and they haven’t thought it through, and that it might make other things worse.

I’d say for everyday usability, what we have is way better. Sure, you deal with timezones, but at least once you know what time it is there you have a good sense of what part of the day they are in.

Currently you look up the timezone, maybe do some maths (but let’s be real, you just search and get given the time) and then you immediately have a good sense of what the time is there, oh cool it’s 7AM.

If we all had the same timezone: you look it up, and then you HAVE to do maths. Why? Oh their midnight is 8, and it’s 15 now, so 7 hours after midnight.

Your mind immediately has gone to oh it’s 7AM, but NO, in this new reality, it’s 15:00 everywhere and where you live midnight is 14:00, so that means where you live it would be like your 21:00.

No matter what time you pick to anchor what time of day that place is, the problem persists. And now you just have replaced the problem of looking up timezones, with looking up when the sun is at some point, and then needing to convert that to get a sense of what time it is there according to the sun.

This would be shit, when you get to a new country when travelling you have to relearn what the numbers “feel” like.

Let’s just keep what we have, this is a solved problem.

KillingTimeItself, (edited )

Currently you look up the timezone, maybe do some maths (but let’s be real, you just search and get given the time) and then you immediately have a good sense of what the time is there, oh cool it’s 7AM.

If we all had the same timezone: you look it up, and then you HAVE to do maths. Why? Oh their midnight is 8, and it’s 15 now, so 7 hours after midnight.

it’s the exact same amount of math in either scenario, arguably even less. Let’s say you’re setting up the time for a meeting with someone across the globe over zoom or something for instance. How does it go? Well you ask them what they’re schedule is like, and you already know what your schedule is like. And both of them use the same timezone instance, because there is only one. So you do no math other than shifting it directly forward and back, the associated amount of time. Perfectly simple. You could also google it ig, but that’s going to the exact same, minus the abstraction that you would otherwise have to do with timezones.

If we all had the same timezone: you look it up, and then you HAVE to do maths. Why? Oh their midnight is 8, and it’s 15 now, so 7 hours after midnight.

This is called a timezone. “Midnight” is the same time everywhere, unless you’re talking about the literal mid night. In which case, yeah that changes, but i’d question why you would need to know that. It’s not like you don’t already know that. Google has already told you. Assuming we’re talking about the date/time midnight, that’s the same time, in every place of the world. Doesn’t matter, midnight here (assuming the 00:00 standard is continued for some reason) is midnight in fucking norway or, sweden, or bulgaria, or your moms house. Doesn’t matter.

No matter what time you pick to anchor what time of day that place is, the problem persists. And now you just have replaced the problem of looking up timezones, with looking up when the sun is at some point, and then needing to convert that to get a sense of what time it is there according to the sun.

See this is where you go wrong, i’m saying timezones SHOULDN’T exist, and then you immediately propose a system that is also just a timezone, they shouldn’t exist PERIOD. There is not link between the solar cycle, and date/time, other than the fact that they exist in a parallel fashion. There is no anchor to what “midnight” is, midnight is just the middle of the night, that might be 2 am, that might be 5 pm, that might be 14:00 who knows. Who cares, it doesn’t matter.

And let’s assume that timezones are nice, because you get up for work at 6am, and they get up for work at 6am, and you both stop at the same time. Sure timezones are nice in that one specific instance because it’s a direct translation, you know what else is a direct translation though? Not having timezones. You could just as easily convert “timezones” into “solar cycle maps” Literally the same thing, they explain the same exact thing, they use the same exact amount of effort.

It’s literally only LESS confusing now.

Your mind immediately has gone to oh it’s 7AM, but NO, in this new reality, it’s 15:00 everywhere and where you live midnight is 14:00, so that means where you live it would be like your 21:00.

There is no 21:00 your time. it’s 14:00 your time. 14:00 is your midnight in that instance, because that’s the time where the middle of the night occurs for you. 15:00 for you is one hour after you midnight, and 15:00. It’s not magically 22:00 now, or 1:00 now. That’s not how that works.

I suppose you could be arguing that you are so entrenched into this particular method of counting, that the numbers the funny paper disc tells you is actually how you control your sleep cycle, but i would much rather argue, uh no. The sun does. Why? Science.

quick edit:

This would be shit, when you get to a new country when travelling you have to relearn what the numbers “feel” like.

Also, news flash, we already have this issue, it’s literally called jet lag. This is a normal occurrence. And also, literally anybody who lives in somewhere that DST exist, does this TWICE A YEAR.

KillingTimeItself,

timezones IMO, shouldn’t exist. The sun cycle is disconnected from actual physical date and time cycle. Just pick a timezone, UTC, or whatever the fuck, unix time, i don’t care, DST or not, i don’t care, and stick with it.

Nothing, the next day is 00:00 You’re adjusting it to match the rising cycle of the sun, not to match the day transition point which is entirely arbitrary, that would just be different. I mean, take a normal clock, flip it upside down. Does it run any differently? Nope. It’s the same, it’s just upside down now.

The date time roll over would be a little weird, but then again we literally already have it. It’s just not synced with the sun cycle. Ask anybody who rolls a late night schedule what they think about midnight. I mean you literally can say what day it is. The date is explicit. The date changes at night, can you say what night it is at night? It literally doesn’t matter.

The date cycling over is universal across every zone, doesn’t change from one place to another. It’s the cycle of the sun that changes. That’s the easy part to adapt to, we’ve been doing it since the beginning of humanity.

then you have the problem where it may be Thursday 4th April 13:00:00 where you live, but actually it’s not midnight yet somewhere else and so simultaneously it’s Wednesday 3rd April 13:00:00 there.

Yeah, we already have that, it’s called timezones. The day night cycle is independent from date time. To TL;DR that entire section, midnight literally just isn’t a thing in that scenario. It’s the date rollover point now.

Like frankly, someone who lives in the midwest, with DST, and long days in the summer, and shorter days in the winter. None of this is a problem. We’ve been collectively doing this async sun cycle/date time thing for centuries. The sun here sets about 3-4 hours later in the summer, in the winter it’s about much earlier comparatively. We adjust our clocks to this twice a year, every year, for every decade, for every century. Our bodies adapt to it. Nothing explodes. (even though arguably it still sucks.)

The problem you list there specifically i think is mostly confusion about the concept of midnight not being midnight anymore, midnight is just called that because it’s the middle of the night, we just happened to choose that as the point where the day rolls over. Sun rise and sun set happen at specific times, weather apps will tell you about this. Nobody seems to complain about those being incredibly variable.

The date rollover is the same in every place in the world. You local day/night cycle is what is disconnected. I could see that potentially being annoying, but then again, we already have concepts of morning, noon, afternoon, evening, etc… I’m genuinely not sure how much this would matter in day to day life. You wake up, it’s one day. You wake up the next day, it’s the next day. You just happen to be awake at the point that it happens. I mean hell it probably wouldn’t even bother most people. Lets say day rollover is noon in 24 hour time somewhere. You tell someone to show up 15:00 on the 8th, which is an impossible date, you just automatically go ok that’s “today” everything before 12 in that scenario is the 7th, everything after is the 8th. 15:00 on the 7th literally isn’t a time that can exist. It’s automatically the 8th. and the advantage here, is that the date rollover point, is the same EVERYWHERE. It literally does not matter where you are on earth.

12 is the rollover point in finland, it’s the rollover point in siberia, it’s the same in china, africa, america, south america, etc… The ONLY thing that has changed is the offset of the day/night cycle in relation to the date/time cycle.

t_veor,

I’m quite confused as to how you’re actually proposing the time should work. I assume that when we talk about abolishing timezones, we mean that everyone switches to a single standard timezone (and that it still goes from 00:00 - 23:59). Are you saying that you would like:

a) The date-rollover point to happen at local solar midnight (i.e. 12 hours past when the sun is highest in the sky in your location, or roughly that), regardless of what the time actually is
b) The date-rollover point to happen at 00:00 standard time, but most people still wake up and go to sleep roughly around when the sun rises and sets
c) The date-rollover point to happen at 00:00 standard time, but most people wake up at roughly 07:00 (for the sake of argument, it could just be any standard time) and go to sleep roughly 22:00, regardless of where the sun is at those times
d) Some other scenario that I didn’t think of?

Maybe I suck at reading comprehension but I can’t tell which system you’re advocating for. I’m also confused when you give the example “15:00 on the 7th literally isn’t a time that can exist”, because however your system works, surely if 15:00 on the 8th is a time that you can refer to, then 15:00 on the 7th is just the time 24 hours before that? (I’m actually just very confused by your scenario. Are you referring to noon as the local solar noon, i.e. when the sun is highest in the sky, or are you referring to when the clock reads 12:00? In both cases I can’t figure out a way to make “15:00 on the 7th” impossible.)

Also I don’t think that the sunrise/sunset times being different throughout the year or that DST exists are indications that the solar cycle is independent of the date. Even if the sunrise/sunset happens at different times of the year, timezones are clearly meant to roughly center the waking day either side of 12:00 on the clock around the solar noon. DST exists to make sure that people get more sun during the afternoon when people are more active, so that both contribute to that the date-rollover point happens when it’s dark out and people are less active.

KillingTimeItself,

I’m quite confused as to how you’re actually proposing the time should work. I assume that when we talk about abolishing timezones, we mean that everyone switches to a single standard timezone (and that it still goes from 00:00 - 23:59). Are you saying that you would like:

simplest possible solution.

to give an example, let’s say we keep midnight as the date rollover. 00:00 of every day would be the rollover point. The date would change at that point, globally. No matter where you are on the world, the time, and date, is exactly the same. That never changes.

Locally, you would account for this by using offsets, i refer to them as timeoffsets, rather than timezones, or time offset mapping, for completion, which gives you a map to your “local solar time equivalent” Most anything you would need to do would be governed by local solar time, or it’s related offset. Work for instance, that’s how it already works, nothing would be different there, just the funny number that the clock shows you would change. This is literally just our current timezone system, but inverted.

As for the example i used, probably not a good one. That was 24 hour time with noon as the roll over point, just for demonstration. So the first twelve hours are one day, the latter half are the second. Given how twenty four hour time works. The first 12 hours of the day wouldn’t be possible on the day after. Essentially, a good way to think about it, would be that it’s like even and odd numbers. You can tell them apart, just by the very existence of them. 15:00 would not be a possible time for the 7th in that example, unless you went back in time. That was just an example of a slip of the tongue type thing. If you were doing anything more serious, you would be planning it better anyway. Noon in that example, local solar noon or not, doesn’t matter, as that’s arbitrary. The point was just a hypothetical.

Though frankly, i think keeping 00:00 as the roll over makes sense, it’s very explicit. Even if it’s midday. That’s a very explicit time change. DST makes the solar cycle aggressively independent of time throughout the year, in each half of the year, so to some extent, it does with date. Like here in the midwest for example, the summer sunset and winter sunset vary by about 4 hours. Which is a thing that changes twice a year, once a year in the one direction. But twice a year for all intents and purposes. Everybody lives with it perfectly fine. I see no reason that 19:00 being the local solar noon would change anything drastically.

My main point there is that we already wake/sleep at different cycles of the day. On the regular, depending on DST, and season. That doesn’t make a huge difference to day to day life. Local solar noon as a concept being noon (more explicitly, 12:00) every day is an entirely arbitrary concept. It’s kind of cute and all, but like i said, if you really care about representation for it, you can just rotate your clock. Noon to me just marks the midday point, and the point where the sun is highest in the sky. I don’t care about the actual time itself. That means nothing to me.

Oh and while we’re at it, standardizing 24hr time would be a good move. 12 hr time is dumb.

brianorca,

The guy that invented time zones was solving a problem where each little town had their own time standard. I don’t think that was sustainable.

ipkpjersi, (edited )

Except if there was only one zone of time that would be hell to program too because then you would need to check for different times of day for different locations. I think programming is just difficult lol

datelmd5sum, (edited )

…but it would be the same time in different locations? E.g. at the time I’m writing this it’s 660DFD56 in New York, London, Moscow, Tokyo, Moon, Mars, Andromeda etc.

kreiger,

you would need to check for different times of day for different locations

You have to do that now with time zones anyway.

Opisek, (edited )

I think the comment was more about phases of the day. Like for example, your phone might come pre-installed with a sleep mode from 23:00 to 06:00, which roughly fits for most users. Should we use UTC everywhere, then you’d have to have different presets for different parts of the globe.

Or say you wake up just a bit after sunrise at 7am everyday and you fly across the continent for vacation. Now you have to change all your alarms because sunrise is suddenly at 3am.

Or what if you’re writing a book and you want to tell the reader what time it is: 15:00 will mean something else to readers around the world. And while you could attempt to cover it up with “15:00 in the afternoon”, there will still be a disconnect between your words/intentions and what the reader pictures.

UTC would be a bliss for programming and scheduling events in this funny little globalized world, but as animals we still base our days on the burning fireball in the sky and removing that connotation from our timekeeping messes with linguistics and clear communication.

I don’t think the system we have is perfect either, but I don’t think employing UTC everywhere is the way and I don’t have other suggestion either.

jdeath,

and then boom congratulations you just reinvented time zones except worse, & everyone’s gonna do their own way and they’re all gonna be slightly different.

but at least your code will be simpler. oh, wait…

LordCrom,

Would be more appropriate if it was the datetime library creator.

uis,

Move to International Atomic Time timezone. clock_gettime(CLOCK_TAI, …) and stop complaining.

AgentGrimstone,

I’m not a developer but give him one for me too

  • All
  • Subscribed
  • Moderated
  • Favorites
  • programmer_humor@programming.dev
  • tacticalgear
  • DreamBathrooms
  • InstantRegret
  • magazineikmin
  • khanakhh
  • Youngstown
  • ngwrru68w68
  • slotface
  • everett
  • rosin
  • thenastyranch
  • kavyap
  • GTA5RPClips
  • cisconetworking
  • JUstTest
  • normalnudes
  • osvaldo12
  • ethstaker
  • mdbf
  • modclub
  • Durango
  • tester
  • provamag3
  • cubers
  • Leos
  • anitta
  • megavids
  • lostlight
  • All magazines