SoylentNews is people
SoylentNews
The Special Commission on the Commonwealth's Time Zone will vote on November 1st on a final draft of a report recommending that Massachusetts move to the Atlantic Time Zone from the Eastern Time Zone:
A commission is studying the possibility of having Massachusetts join the Atlantic Time Zone, putting it permanently an hour ahead of its current Eastern slot.
That would mean later sunsets in the colder months, and would put the state on a zonal par with the likes of Newfoundland, Nova Scotia, and Bermuda rather than the rest of the eastern United States.
The 11-member commission submitted a draft report on the move in September, and will vote on a final one on November 1. If that gets a green-light, the recommendation will go to lawmakers—who may or may not pursue the move.
Maine and New Hampshire would likely join Massachusetts in switching to the Atlantic Time Zone.
2014 editorial on the benefits. Also at NBC.
(Score: 5, Interesting) by Aiwendil on Sunday October 29 2017, @07:30PM (16 children)
Just go with UTC, people will adapt to the whenever stores open and workday starts (varies widely anyways).
And the push for it to be implemented globally.
This will have a few advantages:
* No DST
* No timezones to convert between
* New year parties will diversify
And drawbacks are only for people that move since people will find getting up at 02 to be normal after a while.
(Score: 2) by cellocgw on Sunday October 29 2017, @07:47PM (1 child)
NIce thought, but biology overrules you. Humans simply don't function properly if up at night and sleeping during the day. The bright/dark cycle really matters.
Granted when( :-) ) we all move underground, we can set the artificial sunlight appropriately and all will be well. So to speak.
Physicist, cellist, former OTTer (1190) resume: https://app.box.com/witthoftresume
(Score: 3, Informative) by isostatic on Sunday October 29 2017, @08:45PM
OP wasn't suggesting changing the time you get up. If you currently sleep at 2300 and rise at 0700 in the winter in New York local time, you'd simply get up at 1200 and sleep at 0400. If you do 0600-2200 hours in Singapore, you'd instead rise at 2200 and sleep at 1200.
(Score: 3, Interesting) by Anonymous Coward on Sunday October 29 2017, @09:04PM (2 children)
No that isn't a real solution. The reason is that you move from explicit time zones to implicit time zones. Sure, you'd eventually adjust to the area around you doing their times at whatever. But we are in a global economy. If I want to know what my relatives in Alaska are doing, I just have to ask Google for the time there to get a good idea. No time zone and I'd have to guess, or find out when "noon" is and do my best math or Google local businesses and guess or something.
(Score: 4, Interesting) by Aiwendil on Monday October 30 2017, @12:19AM (1 child)
Just like how it is when calling people today - you need to know their current rythm (I know lots of shift-workers).
Still instead of searching "time in alaska" you'd just search "workday in alaska" (most likely new concept to enter) and it will problaby answer with "ended X hours ago and will start in Y hours".
I'd take using a new word in search engines any day over the hassles that arises whenever (multiple) timezones and/or DST comes into play (most of europe went back to standard time yesterday)
(Score: 2, Insightful) by Anonymous Coward on Monday October 30 2017, @09:58AM
Time zones are one thing, and very useful, DST is another, and should be nuked from orbit. Of Proxima Centauri.
(Score: 3, Interesting) by Thexalon on Sunday October 29 2017, @11:18PM (6 children)
The other extreme: Instead of hourly time zones, have time be set on a municipal level to local solar noon and make computers do all the conversion math for you depending on where you are. So, for instance, when it's 12:00 PM in Springfield MA, it's 12:05 in Boston MA. Which sounds really confusing, except that all the meeting scheduling tools and travel schedules and such factor that in so you never have to figure it out yourself. This all sounds nuts to us modern folks, but humans often did something along these lines prior to trains and telegraphs that would require somebody in Springfield to coordinate closely enough with somebody in Boston that the 5 minutes mattered.
Computers would have to run on UTC of course, which they should be doing now anyways.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 2) by Aiwendil on Monday October 30 2017, @12:23AM (1 child)
I actually agree - after UTC that would be the best thing to do. If you can't agree on a time then just use whatever makes the most sense locally (and states/small countries are too big for local).
(Score: 1, Informative) by Anonymous Coward on Monday October 30 2017, @04:16PM
Actually, time zones were an effort to fix the issue of every town having its own time and not being in sync with those around them. Made life hell for the train companies.
(Score: 2, Informative) by pTamok on Monday October 30 2017, @08:55AM (3 children)
Computers would have to run on UTC of course, which they should be doing now anyways.
Well, yes, and no. Ideally, computer clocks should be monotonic, and UTC is NOT monotonic: it has leap seconds [wikipedia.org]. This is a pain, especially when dealing with logs of transactions that each take less than 1 second.
Here's an article on clock monotonicity and computing: https://www.softwariness.com/articles/monotonic-clocks-windows-and-posix/ [softwariness.com]
People who take an interest in such things will point out that the details of correct timekeeping are extraordinarily complicated. And many programmers make unjustified assumptions, like:
1) All minutes have 60 seconds (Leap seconds make that wrong)
2) Time never goes backwards (if your computer is traversing time-zone boundaries e.g. on a ship, it can. Substantially.)
and many, many others. These two postings are well worth reading:
1) Falsehoods programmers believe about time [infiniteundo.com]
2) More falsehoods programmers believe about time; "wisdom of the crowd" edition [infiniteundo.com]
While such a thing does not exist, and I am not an expert in the matter, I suspect the 'best' time for a computer to run at would be the closest possible approximation to Terrestrial Time (TT) [wikipedia.org]. the trouble is, TT gets revised every so often, which may itself be more disruptive than UTC's leap seconds, from a programmer's point of view. I would love to have a time expert's opinion on how computers should approach timekeeping, especially when you want monotonic timestamps on sub-second transaction logs.
An example might help: assume you have a trading application and the markets are open in Hong Kong and London. Knowing which trade occurred before another is important. How do you record trades in London and Hong Kong so that when you review/combine the log of trades on the computer in London against/with the log of trades on the computer in Hong Kong, you end up with all trades occurring in the correct order. Now add New York, Frankfurt, Singapore and Chicago in the mix. (I have no doubt this is a solved problem. I just don't know the solution.)
(Score: 2) by Aiwendil on Monday October 30 2017, @08:20PM (2 children)
Not an expert but just use the time elapsed since a given time (UNIX epoch is 00:00:00 UTC on 1 January 1970, so unix time is the number of seconds since then) - if you want a timezone just do the math for the timezone in question.
(Score: 1) by pTamok on Monday October 30 2017, @10:17PM (1 child)
If you look at the definition of UNIX time [wikipedia.org], you'll see why that might not be correct.
(Score: 2) by Aiwendil on Monday October 30 2017, @11:52PM
Yikes, thanks for pointing that out.
Well, the notion of using all seconds since epoch still holds true as a decent solution - just seems we ran out of shortcuts.
(Score: 0) by Anonymous Coward on Monday October 30 2017, @01:34AM
I don't feel like changing my schedule to UTC. Everyone should just switch to EDT.
(Score: 0) by Anonymous Coward on Monday October 30 2017, @03:21AM (2 children)
>And the push for it to be implemented globally.
If the Earth is not flat but a globe, how will the Sun manage to rise and set at the same time for everyone on Earth? What's the geometry of that? Mirrors in space? A one-world government? Maybe order all the people to move to one longitude? What about the ones who don't want to move, are you proposing genocide? I don't think it's worth it just to simplify the timing of phone calls.
>* No DST
Sign me up because that's a cause worth dying for! Make no mistake, many of us will. We're going up against most of North America and most of Europe but we have Ukraine, Russia, most of Africa and all of Asia except Iran [wikipedia.org] on our side. As well as the best parts of South America and Australia. We can win it. And it makes far more sense than the first and second world wars.
(Score: 3, Informative) by Aiwendil on Monday October 30 2017, @09:16AM (1 child)
Why rise and set at the same time? Even when measured in local time it doesn't currently - for instance Luleå (sweden) and and Rome (Italy) is in the same timezone and today the sun rose at 07:16 and 06:40 respectivly (around christmas the diff is about 2h15min) and those roughly align longitudinally [funnily enough Rome is somewhat west of Luleå; while Atens(greece) and Luleå aligns better Greece is in another timezone. Oh, also, Rome and Madrid (spain) are in the same TZ and in Madrid the sun rose at 07:42)
All I'm proposing is getting rid of the "day starts between oo-12 (and ends between oo-04)" (I live near the arctic circle - some days you tend to miss when it goes from sunset to sunrise, or vice versa).
If you want the sun to rise and set at the same local time you should also take north-south into account.
(Score: 0) by Anonymous Coward on Monday October 30 2017, @08:59PM
Interesting, having sunrise and sunset coordinated along a north-south line throughout the year...
It would probably require mandating that "sunrise is at 6 am, sunset at 6 pm" so day-minutes and night-minutes would vary in length during the day (except the equinoxes) ... and during the year...