Ok so there are 24 time zones. Before that every town had their own time based on the sun. We basically went from infinity time zones down to 24. This is in fact simpler.
(There are some half hour time zones too,(India, Newfoundland) so at least 26.)
there are 24 time zones
Cunningham’s law says that this will generate some discussion in the replies!
There are a few time zones that are 45 minutes off, like Nepal Standard Time which is UTC+5:45, some places in Western Australia and South Australia use UTC+08:45 and the Chatham Islands are at UTC+12:45 or UTC+13:45 in summer.
DST means you also have things like CST vs CET and given some places start DST earlier or later than others and some ignore it all together, we probably have at least 50 time zones.
Always fun trying to schedule international regular meetings when suddenly there’s a week when half the people’s times changed and the other half’s times haven’t yet, so you try to figure out which time would exclude the fewest essential people.
Absolute madness. smh my head
I’m not a developer but give him one for me too
DST had good reasoning at the time. It doesn’t anymore.
The US tried no dst back in 1970. After 2 years people wanted it back.
Is it still 1970 today?
What is so different today that people wouldn’t change their mind again about DST?
It’s 54 years later. Are you expecting a full list or something?
So because you read the news on your phone instead of the newspaper somehow everything is different with the sunrise?
You’re right. The only thing that has changed is that newspapers are smaller.
If the list is so long, then it should be easy to list one thing that is different today that would make people not want DST.
I don’t need a list. Just one example.
They did permanent DST instead of no DST (permanent standard time), so they had dark mornings in winter.
I’m ok with timezones, but the guy who invented daylight savings time I’d slap to all the way to the sun
Isn’t that Benjamin Franklin or did West Wing lie to me?
Switching sucks but DST is better than Standard Time.
Which part of the year is DST and which part is Standard Time?
I know, but it seems like half the people that say they prefer DST have it backwards.
i still dont even understand what DST even is, as far as i care because i don’t is that DST just means we change the time, because god forbid the time be a little funky.
DST is shifting the sunlight later in the day during the summer.
too bad there isn’t like a standard convention that establishes when something would take effect, how it would take effect, and at what interval.
No, daylight savings time is definitely what we’re going to call it.
It’s easy, the good part is DST (which is what we’re currently in - Spring through Fall in the northern hemisphere).
It’s only good from spring to fall. Come winter and it’s a permanent depression.
Strong disagree, under DST I get to experience some sunlight in then evenings. Under Standard time I get to watch the sun come up through the window and set through the window.
just move somewhere better. don’t mess up my timezone just because your weather always sucks!
I don’t know what you mean by evening, but it’s already dark at 16:00 during winter. You only get some light in the morning. DST means no more light in the morning and no more light in the evening. Complete depression. DST should not exist.
Standard Time during that period is what’s depressing.
yeah it’s literally ass-backwards. how can anyone support DST as it stands is beyond me
With standard time you get some light in the morning. With DST you get no light at all. Also there’s nothing worse than waking up in the darkness.
Sure there is… Coming home from work in the darkness is way worse than waking up in it.
The real problem is that across the globe there is like 50 different implementations of it. Some places have a fucking half hour, or some goofy shit. Really fun handling time zones with that sprinkled on top.
DST vsm Standard time literally doesn’t matter. It’s the switching between the two that kills people.
IIRC daylight savings was created way back when electricity really didn’t exist so it allowed the farmers more daylight to harvest their crops.
Now with that said there is more technology in today’s farming equipment so DST shouldn’t really exist anymore.
So, this is wrong on so many levels. First of all, DST had nothing to do with farmers, it was to save energy usage in the summer as people were doing more things after work when the evenings were warmer.
IIRC daylight savings was created way back when electricity really didn’t exist so it allowed the farmers more daylight to harvest their crops.
DST does not increase the amount of daylight on any specific day of the year, it just shifts it later in the day so that people in 8-5 jobs can do more things after work. Farmers don’t work 8-5, they work as needed so if the crops need harvesting they will get harvested based on the weather.
Now with that said there is more technology in today’s farming equipment so DST shouldn’t really exist anymore.
Nowadays farmers have lots of lights and can harvest after the sun goes down, but that has nothing to do with why DST shouldn’t exist. DST shouldn’t exist because it doesn’t save energy due to any populated place having their lights on all night and the actual changing of time leading to negative outcomes like deaths from accidents with no benefits.
Sure, the sun will come up earlier and set later in the summer if we get rid of DST, but the only reason for the time change in the first place was the standard working hours being longer after noon than before.
Actually DST was a war world one thing to save energy. To not need lighting in the factory.
Look it up you’re both wrong.
It actually was only active during WWI and WW2 until late 60s or early 70s (oil crunch may have brought it back.)
Originally being started for WWI and WWII doesn’t contradict my post which talks about the current reasons given to keep it and that it is not saving energy now.
Oof just 90%
“Midwestsocial”
Yup that explains the lack of reading comprehension…
Good day
Why does my location impact your reading comprehension?
Smh my head
And you’d think farmers would want more sunlight in the morning when it’s cooler.
Farmers don’t care about clocks unless they are scheduling a time to meet and using the clock for clarity.
The sun comes up when it comes up and that is what matters. Farmers don’t care about the clock for what they consider morning, because morning is before the sun is highest in the aky. They are already getting up a few minutes earlier or later depending on whether the days are getting longer or shorter.
DST has nothing to do with farmers.
I think you misread my comment. It’s along the lines of if anything they would prefer the morning.
This is like saying dogs would want better stock options when stock options don’t matter to dogs.
This is besides what I was saying, which was again “if anything”. But dude people live in the world. Farmers are not 1000% in their own bubble. They need to go out to stores and get supplies and interact with the world and the supply chain. You are now taking lack of an office schedule or something to a ludicrous degree with your analogy. I wasn’t even disagreeing with your old points, I was saying “if anything” and adding another reason why farmers and DST makes no sense, but you want to go off on seemingly everyone. Perhaps you’re confusing me with the other guy, but whatever. Cheers.
My understanding is DST did still save appreciable energy until we replaced incandescent lights with fluorescent and leds. Longer daylight in the evening when people are awake and less in the early morning when people are asleep means lights aren’t being used as much. The average light bulb used to consume 60 watts or more and also let off significant undesirable heat, so with a house full of lights DST really did cut back energy usage. Now though with led lights low consumption and virtually no heat, it’s not nearly as significant.
and set earlier in the summer*
I hate it. I fucking hate it. With every fiber of my being. I spend every winter counting the days until the sun stops setting before I stop working. Our entire lives are scheduled so we are inside under neon light from 9-6, why are we trying to maximize how much of that is during daytime?
On the day that we go back to permanent ST I will turn to hard drugs to make up for the dopamine deficiency. No joke very few things in my life fill me with more dread than having to suffer early evenings for the rest of my life.
Maybe, and hear me out, the problem is that 9 to 6 is the problem, since 2/3 of that time is after noon. Instead of changing reality to appease business, business, work hours could be changed to 8 to 4 with four before and four after which is both more light in the evening than DST and a shorter workday because people are more productive than they ever have been.
But I guess you would rather let business practices determine when noon is for everyone instead of the sun.
Business hours is no more or less of a social construct than DST or the 24 hour clock.
The only difference is that we have a shot at making everyone agree on a timezone shift or permanent DST, but absolutely NO SHOT at getting every business to switch to an 8-4 schedule. None. It’d be a nice sentiment. But it’s not happening, and I don’t care what the number says on the clock when I leave work as long as it’s sunny outside.
Why is it so important that the sun reaches its zenith at noon anyway? Do you often get confused while looking at your antique sundial?
First of all, noon refers to when the sun is at the highest point in the sky so being an hour off is confusing.
Being able to look at the general position of the sun and being able to estimate time is pretty handy.
Being able to estimate the length of day because the time between sunrise and sunset being approximately the same is handy.
Not changing the time of day twice a year would be fucking fantastic.
Some places already stick with standard time all year round.
The US tried year round DST in the 70s and it was widely rejected within a year because DST during the winter is fucking awful.
Plus, most jobs don’t mind people coming in and leaving early, which is a far more common shift adjustment than coming in and staying late.
Year round standard time is the real solution.
It was some worker who wanted more time after work to catch butterflys.
It’s not about the crops, farmers work by the sun, not by the clock.
It was able conserving candles and oil, for lighting rooms.
That is literally the opposite of true.
That’s a misconception. Farmers lobbied heavily against DST. Their work does not abide by the clock; they milk when cows need milking, and they harvest when there’s enough light, no matter what some clock says.
In Europe, DST as we know it now was first introduced by Germany during WW1 to preserve coal, then abandoned after the war, and widely adopted again in the 70s. In the US it was established federally in the 60s.
This is all glossing over a lot of regional differences and older history. But yeah, US farmers were very much against the idea.
I blame Big Ice Cream™.
Those ice cream trucks get an additional hour of daylight to hawk their goods before the children are recalled back inside for supper.
I love DST! I just think ever switching out of it is where the mistake lies
DST during winter = permanent depression.
You are aware that the actual amount of daylight doesn’t change when we move the clock’s right?
It really comes down to when you’d rather have more daylight, morning or evening.
Evening
Agreed. That’s why DST is best.
Except that it doesn’t. Take a look at daylight data for 20 Dec here https://www.timeanddate.com/sun/uk/london
Daylight: 08:03 - 15:53
That’s ST obv. Now let’s convert it to DST, that will be 9:03 - 16:53. Let’s say you work a standard 9-5 job. Well, 9:03 is after you start working and 16:53 is before you finish. Thus you get ZERO daylight during the day in DST. You get almost an hour in the morning with ST.
Now let’s move further away from equator https://www.timeanddate.com/sun/latvia/riga
Daylight: 08:59 - 15:43
Well, DST is a perma fucking depression now as you’re robbed from the very few minutes you had before.
How about further North https://www.timeanddate.com/sun/finland/helsinki
Daylight: 09:23 - 15:12
No wonder Finland has such high suicide rates during winter…
P.S. It is also worth noting that daylight grows the closer you get to the equator and it grows in the morning, not in the evening. You can see from the examples above that their evening difference is smaller than the morning one. There’s just no point having DST.
I’m missing your point. Do you think that moving the clocks is having an effect on the tilt of the earth? Or are you just trying to explain to me how daylength and latitude are related?
I know quite well how dark it gets in the north. I live in the north. Luckily, the sun still rises and sets at very predictable intervals. If I want to enjoy sunlight, I simply need to be awake at some point that coincides with when the sun is up.
You are also aware that not everyone works the exact same hours, right? And windows exist?
Use a different example to make the opposite point: I’d like the sun to be out for at least an hour after I get home from my “9-5”, so if the sun sets at 1700 I’m standard time, I am depressed. But in DST, I get to spend an hour in my garden.
See? The debate is stupid. Do you want more daylight in the morning or afternoon. That’s the only question. The amount of daylight is not affected by clocks.
Wut? If it’s DST during winter, you don’t have any light to enjoy after work. You can only enjoy light in the morning with ST. All the explanation is above, with facts.
From a development perspective it certainly sounds easier to have one global timezone with DST than a bunch of smaller ones without it. Would that make sense in reality? Probably not but I definitely think timezones take more work to compensate for properly.
What matters is consistency and our time system has tons of crazy inconsistent shit in our. Everyone knows about leap years, but do you know about leap seconds? Imagine trying to write a function to convert unix time to a current date and suddenly all your times are a second off.
Just look at this insane bullshit nonsense. The added complexity of time zones and daylight saving time is nothing compared to simply supporting our time system.
We need to synchronize all computer times with that one clock that can stay accurate to within 1 second every 40 billion years.
We do? With NTP
I’m referring to this one, the most bleeding edge of accuracy. I don’t think NIST would have implemented this particular clock (yet).
Not really. Timezones, at their core (so without DST or any other special rules), are just a constant offset that you can very easily translate back and forth between, that’s trivial as long as you remember to do it. Having lots of them doesn’t really make anything harder, as long as you can look them up somewhere. DST, leap seconds, etc., make shit complicated, because they bend, break, or overlap a single timeline to the point where suddenly you have points in time that happen twice, or that never happen, or where time runs faster or slower for a bit. That is incredibly hard to deal with consistently, much more so that just switching a simple offset you’re operating within.
Lets just have 2 timezones, Chinese time and EST w/ permanent DST. The most populated timezones for Eurasia and the americas, and they’re both 12 hours apart.
There was actually a really interesting idea I heard to have no time zones. And I actually think it could be a good idea. It’ll never happen because people would need to re-learn time but if it was always the same time everywhere it would make scheduling and business so much easier. No one would need to convert between different zones or be late because of an incorrect conversion. The downside is that times which are conventionally morning or evening etc, would no longer would be so people would have to get used to time just being a construct for scheduling and not a representation of the natural day/night cycle…but it actually doesn’t sound like a half bad idea.
Problem you run into is the areas where we need to tie things to solar days across an area.
You end up with places having to regulate that school starts at 22:00, and gets out 05:00 the next day.
Businesses close for the night at 06:00 and open bright and early later that day at 22:00.
You have places where one calendar day has two different business days in it, so the annoyances faced by people who work overnight shifts spreads to everyone, and worse gets spread to financial calendars, billing systems and the works.It’s not better.
🤔 that’s a fair point…
Time is an air bubble trapped under a screen protector. It’s annoying, and you can push it around to try to keep it out of the way, but you can never really fix it.
There’s just too many inherently contradictory requirements for us to end up with a “good” system, and we just need to settle for good enough.My dream is that we stop changing things. Whatever we have in time zone database today is what we stick with going forwards. No more dst shifts, no more tweaks to the zones, no more weird offsets and shifts, because we don’t get to stop dealing with the old layout when we change, we just add a new one that we think is better.
For the most part, dealing with this stuff is a solved, shitty problem. It’s when we change the rules that problems come up. Worse when we change them retroactively. (Territory disputes between nations have been resolved with the conclusion that land was actually in a different time zone in the past because it was actually in another country. Not a problem usually, unless there’s a major stock exchange in an island that was transferred between nations and retroactively changing what time it was affects what laws were valid at the time certain transactions took place.
and id put him back and lovingly nurse him back to health. big hero.
Love me some early evening daylight though. Nice warm but not hot cruise/drive with the windows and the top down on the car.
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.
Soon we’re going to have a new timezone for the moon. Yay, I guess?
Surely they will just use utc?
Can’t be that simple due to time dilation effect. Time moves at a different rate in moon, about 1s difference per day.
https://www.reuters.com/science/white-house-directs-nasa-create-time-standard-moon-2024-04-02/
That article says 58.7 microseconds per (Earth) day. Not 1s.
Shit you’re right, I misremembered it.
Appreciate you correcting your post, just one more needed.
ms = milliseconds
us = microseconds
Easier to just round up lol
Would be more appropriate if it was the datetime library creator.
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
…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.
you would need to check for different times of day for different locations
You have to do that now with time zones anyway.
I think thu 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 is 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 you 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 in: 15:00 will mean something else to readers around the world. And while you could attempt to cover it up with “15:00 it 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.
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…
But if time travel is a thing, imagine the whole new time nightmares! Oh you went back a year with your phone? Now all your TLS root certs are invalid because you’re before the start date. Or you have files/emails/whatever that are dated in the future. I guess you can get to that state by just setting your clock forward but I imagine some stuff would break.
I worked on a project that had a few spots where we compare a saved timestamp to the current time. During testing, the client would randomly change their device time a few days forward or backward and complain that things weren’t working as expected. I had to explain to them multiple times that they were basically time traveling, and the program was actually handling it fairly well all things considered.
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.
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.
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.
I agree. It’s written like “ugh I’m used to timezones, now what?”.
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.
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.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.
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.
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.
I identify as a time radical. We should switch the entire world onto GMT; +/- not a goddamn thing. Is it perfect? I think so, but all those people who might be confused will probably find it a lot less confusing than trying to make sense of the difference between timezones.
GMT has leap seconds. TAI does not. Switch world to TAI.
Worked on a project where devices just magically froze, but only during the month of February!
Turned out the people who had written the firmware had decided to do their own time math to save space and had put in an exception in the code for leap year values. Except instead of February 29th, it kicked in for the whole month. And the math was wrong so you ended up with negative values.
The product was due for launch in March of that year and was headed to manufacturing. It was by sheer luck that someone ran a test on February 1st and caught the problem.
Don’t mess with time in code, kids.
This is why we have pre-built libraries and Unix time.
Embedded portable device with a teeny ARM processor. Sadly, no room for linux anything or even an RTC. Every time it connected to a phone, the phone would set its clock so the timestamps were somewhat close to being accurate.
However, if you swapped out the AAA battery and DIDN’T connect it to the phone at least once, all your subsequent readings would go back to zero epoch and would be forgotten 🤷🏻♂️
Good times.
Some absolute and utter legend of a man made a Unix kernel for the fucking ZILOG Z80, you have no excuses
(It’s called UZI and it’s written in K&R C for some obscure CP/M compiler)
If it had been up to me, I would have included a proper real-time-clock in the design and done things a lot differently.
But the device was designed by one company and the BLE and processor module by another. For some ungodly reason neither trusted each other, so nobody was given access to the firmware source on either side. I worked for a third company that was their customer paying the bill. I was allowed to see the firmware for both sides, but only read only, on laptops provided by each company, one at a time, in a conference room with their own people watching everything. Yeah, it was strange.
I was there because the MCU and the BLE processor sometimes glitched and introduced random noise. Turned out the connection between the two parts were unshielded UART with no error detection/correction 🤦🏻♂️
It was concidental that we hit the date glitch. Took all our effort just to get them to add a checksum and retry. The tiny MCU was maxed out of space. No way to fit in any more code for date math.
God I’m sorry you had to go through that much middle management bullshit
Thanks. On the plus side, I got to try ‘soup dumpling’ – still the best I’ve ever had. And Kaoliang, the most gut-busting distilled beverage known to mankind. OTOH, the product shipped, won lots of awards, and got national coverage for the company.
Nothing to do with timezones, but still, fun times.
Unix time.
Unix time doesn’t help with timezones… It’s always in UTC.
Unix timestamps also get a bit weird because of leap seconds. Unix timestamps have no support for leap seconds (the POSIX spec says a Unix day is always exactly 86400 seconds), so they’re usually implemented by repeating the same timestamp twice. This means that the timestamp is ambiguous for that repeated second - one timestamp actually refers to two different moments in time. To quote the example from Wikipedia:
Unix time numbers are repeated in the second immediately following a positive leap second. The Unix time number 1483142400 is thus ambiguous: it can refer either to start of the leap second (2016-12-31 23:59:60) or the end of it, one second later (2017-01-01 00:00:00). In the theoretical case when a negative leap second occurs, no ambiguity is caused, but instead there is a range of Unix time numbers that do not refer to any point in UTC time at all.
Some systems instead spread a positive leap second across the entire day (making each second a very very tiny bit longer) but technically this violates POSIX since it’s modifying the length of a second.
Aren’t timestamps fun?
Luckily, the standards body that deals with leap seconds has said they’ll be discontinued by 2035, so at least it’s one less thing that developers dealing with timestamps will have to worry about.
Don’t try to write your own date/time code. Just don’t. Use something built by someone else.
Unix time doesn’t help with timezones… It’s always in UTC.
Unix timestamp is always in UTC which is why it’s helpful. It’s seconds since Jan 1st 1970 UTC. Libraries let you specify timezone usually if you need to convert from/to a human readable string.
Don’t try to write your own date/time code. Just don’t. Use something built by someone else.
…yes that’s why UNIX timestamps are helpful, because it’s a constant standard across all the libraries.
Some systems instead spread a positive leap second across the entire day (making each second a very very tiny bit longer) but technically this violates POSIX since it’s modifying the length of a second.
Then that system should be trashed.
Unix timestamp is always in UTC
Careful with the exact phrasing here - while the epoch was at midnight in GMT, the time from which time_t is measured also exists in other timezones.
Then that the library that does it should be trashed.
UNIX time is trash.
Unix timestamp is always in UTC which is why it’s helpful.
Any time you show the time to a user, you have to use a timezone. That’s why the unix timestamp has limited usefulness - it doesn’t do a lot on its own and practically all use cases for times require the timezone to be known (unless you’re dealing with a system that can both store and display dates in UTC). Even for things like “add one week to this timestamp”, you can’t do that without being timezone-aware, since it’s not always an exact number of seconds as you need to take Daylight Saving transitions and leap seconds into account.
Then that system should be trashed.
A lot of systems just don’t handle leap seconds well. Many years ago, Reddit was down for four hours because their systems couldn’t deal with leap seconds. Smearing the extra second across the whole day causes fewer issues as software doesn’t have to be built to handle an extra second in the day.
Luckily, the standards body that deals with leap seconds has said they’ll be discontinued by 2035
Did they figure out a way of making the earth spin more reliably per how the humans want it to?
If I remember correctly, they’re updating the standards to allow for more deviation between UTC time and “actual time”. They’ll likely replace leap seconds with a leap minute that happens much less frequently, implemented by spreading it across the whole day, similar to the leap second workaround I mentioned.
too bad unix time only has 14 years of life left in it.
No
Was it related to banking?
Consumer health.
Good product, too. Won a bunch of awards. Unfortunately, the company has since gone out of business.
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.
time always goes forward
It not always goes and not always forward. I think you need metric time(TAI) instread.
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.
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.
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…
not unless somehow the system clock was modified while it was running…
Which is how most systems handle leap seconds.
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.
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.
Standardising on EST is fine; it’s just UTC plus a constant. If they flipped between EST and EDT, now that’d be insane.
Yes as long as the rules are known, but it’s really just better to do things sanely and leave no margin of doubt.
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)
