I don't mind ditching DST. It's a mess. Not sure why it's still in use.
In my country (Poland) there was such an initiative, but was turned down by officials. Their explanation was that "EU law does not allow that" (a single state to ditch DST).
Time to Dump Time Zones
221–230 of 555 posts
Re: Time to Dump Time Zones
#222Earlier quoted context omitted.
It's not quite that simple. Timezones change (less often than postal codes, but across the world, it's still a bunch of maintenance changes). Getting rid of timezones would be simpler and reduce a monumental number of bugs (as well as code and potential problems). See the Russian changes! https://www.timeanddate.com/news/time/
Only a few people have to maintain the time zone system, and only a few people (those writing the software that everybody else uses) have to understand the minutiae. The alternative is that everybody has to understand, which will invariably cause many mistakes. I mean, when someone schedules an across-timezones meeting they use software anyway; and who really cares about that one time 2 decades ago when some small re…
Medical software certainly does. I imagine financial software as well.
Re: Time to Dump Time Zones
#223I've spent the last several years developing applications that have calendaring at the core, where users collaborate across timezones, and where proper timezone handling is expected. Just try to explain to everyday people just how hard the problem is, the technical in and out, the practical miracle that it all works in almost all the cases, that all the error prone complexity can be eliminated by acknowledging that i…
In my experience it's better to store local time (where the event physically happens) with a named timezone. That way when daylight saving laws change with 3 weeks notice you can adjust without shifting events (cough Outlook). UTC can be calculated easily if needed.
This is a really good point and I don't disagree with it. I'd tend to prefer to store in UTC and store the associated timezone separately.
Re: Time to Dump Time Zones
#224Earlier quoted context omitted.
Why do you think so? I believe it would work better than the current system. We could utilize roads, vehicles, parking space, other infrastructure, as well as manpower more evenly. Rush hours are a weird concept and painful for pretty much everyone every day - waiting in traffic or lines is not much of a joy. The fact that 9-5 workers all work at the same time means that any one worker doesn't have much chance to tak…
Well, for one thing, a great many people commute to their jobs. For another, I doubt the zones would be far enough apart in hyper-local time for this to actually help congestion at all. That's before we account for headaches of the time changing six times as you drive to the grocery store.
I think in the future the number of people commuting to their jobs will be decreasing. Anyway, let's keep to the present.
You could optimize the location of the zones for traffic. For example, we know that everyone will sleep at some point, so the resting zone could be at the center of the city. Then throughout the day, people would commute in and out of the center in all directions at about a constant rate. That's already a lot better if you consider road and parking space utilization, than 2x1 hour rushes in specific directions like we have now. The main benefit is spreading traffic across time, not space though.
Also, rush hours are not limited to traffic. You can experience them in stores, offices, restaurants, pretty much everywhere as most people with 9-5 jobs try and run their errands in the very limited time before/after work.
And time wouldn't change between zones, neither would our measurement of time. This is all in addition to abolishing time zones. Once you dump the notion of 'local time night is for sleeping, local time 9-5 is for working' all this seems like the next logical step to me.
Re: Time to Dump Time Zones
#225Earlier quoted context omitted.
Well, for one thing, a great many people commute to their jobs. For another, I doubt the zones would be far enough apart in hyper-local time for this to actually help congestion at all. That's before we account for headaches of the time changing six times as you drive to the grocery store.
I think in the future the number of people commuting to their jobs will be decreasing. Anyway, let's keep to the present. You could optimize the location of the zones for traffic. For example, we know that everyone will sleep at some point, so the resting zone could be at the center of the city. Then throughout the day, people would commute in and out of the center in all directions at about a constant rate. That's a…
"Once you dump the notion of 'local time night is for sleeping, local time 9-5 is for working' all this seems like the next logical step to me."
Can you expand on this? I read this as setting up schedules to potentially rotate everyone's sleep/work schedules, independent of the diurnal cycle. Though I wonder if I'm not reading too much into it.
Re: Time to Dump Time Zones
#226The advantage of daylight savings is I can set my schedule to wake up at the same time each day, while maximizing my daylight hours and never getting up before dawn.
Without the shift for daylight savings, the sunrise time in San Francisco varies from 5:47a at the summer solstice, to 8:25a just after winter solstice. If I set my schedule to get up at 8:25a every day, I'd miss a significant amount of morning sunlight.
The beauty of daylight savings is it shifts the sunrise time to be earlier in winter, so instead of 8:25a the sun rises at 7:25a. Thus I can set my schedule to get up at 7:25a and get an extra hour of sunlight every day.
(Technically the latest sunrise time is just before shifting from daylight to standard, 7:39a on November 5 - the point is we reduce the range of variation from 2hrs 38min to 1hr 38min)
Re: Time to Dump Time Zones
#227Earlier quoted context omitted.
Only a few people have to maintain the time zone system, and only a few people (those writing the software that everybody else uses) have to understand the minutiae. The alternative is that everybody has to understand, which will invariably cause many mistakes. I mean, when someone schedules an across-timezones meeting they use software anyway; and who really cares about that one time 2 decades ago when some small re…
Medical software certainly does. I imagine financial software as well.
Sure, but there it's on the programmer. Which is exactly what I mean - it's better to shift the onus to the few than having everybody needing to care about it.
Re: Time to Dump Time Zones
#228Global, linear, synchronized utc time for computers, and local noon when sun hits zenith, for humans.. would be my preference.
Re: Time to Dump Time Zones
#229Hmm...this is an interesting idea. However, the core of the argument seems to be this: > “The economy — that’s all of us — would receive a permanent ‘harmonization dividend’ ”— the efficiency benefits that come from a unified time zone. But this editorial is pretty light on actually supporting that. The basic argument seems to be that it reduces 'translation costs'. But..does it? What about the benefits of being able…
The NY author convinced me about the Earth time, and you got me back. You are right, a change like this would create other problems, as you cited.
How did he convince you? He didn't make a strong argument for it at all. The whole article seemed like an excuse for him to show off his flowery language and tell a couple anecdotes of people abusing time zones. His actual proposed solution was half-baked at best.
Re: Time to Dump Time Zones
#230Earlier quoted context omitted.
Yeah agree completely. And keeping zones is important to understand workdays. I wouldn't mind dropping named time zones completely in favor of UTC+Offset, I always end up looking that up, annoyingly. Or just name the zones based on the offset. So NY would be -5. We could for humans write time with the ecoding, similar to ISO-8601, but it would just be 15:30-5 for 3:30pm EST. While we're at it. Can we make all the mon…
Your math doesn't work out there though. If we had 30 day months, we would end up with 360 days spread among 12 months, and an extra 5 days leftover. 28 day months make far more sense, would align nicely with your proposed single New Year's day, and have the added bonus of aligning with our 7-day week system quite nicely. This ends up with 13 months altogether, and hey, it turns out that 28 days is closer to a lunar…
Ah. I screwed up my math. 28 sounds perfect.
I rely on unit tests for this stuff these days ;)