Is there still a valid reason to have timezones altering between states? is it just for agriculture?
While we're, talking about changing time monitoring systems, can't we have 13 months with 28 days each? (and an extra day every 4 years added on to december?) :(
Simple things, but that would allow us to follow the lunar cycle.
Our timezone/calendar system is convoluted, but that's because there are inherent issues with any calendar reform. I recommend looking at the following articles:
All of these are valid points but when we get the ability to force the earth's rotation, orbit, and the moon's orbit to specifics then I WILL SHOW YOU.
You're confusing time zones with daylight savings. Time zones exist so that the same part of the solar day has approximately the same time associated with it wherever you are in the world (prior to the railroads, that was the only time - local time). So I can say "it's 4am in China" and you'll know it's the middle of the night without having to consult Google. They can also achieve the opposite, keeping neighbours on the same time when their solar days are actually different, e.g. within China. Sometimes that's useful.
Daylight savings exist for saving power (and were introduced in the war to do just this), providing more daylight hours for school children, and longer days for agriculture (now historic). There is debate about whether any of those reasons are actually valid.
The fact that you just said this, in this context, shows me how clearly embedded the AM/PM 'standard' is for people. Though that doesn't mean it's still a good idea to use it for meetings. It just signals to me that the only way of displacing this imprecise messy standard is to teach people to schedule meetings differently; and to have their smartphones display both the AM/PM time, and the standard meetings time.
Unfortunately that would probably still be as a 'timezone', and if we're doing that it may as well just be UTC since every timezone library I've every used already has that and best of all is only off by a few seconds at most without updates. (Close enough for applications that care about timezones instead of leap seconds.)
I asked farmers about this. They said it was stupid now that we have electricity. And even then, with the shorter days.. it was still stupid. (I'm quoting them)
I wish people would quit repeating the farmer myth. No farmer I have met wants daylight savings time. Look at Indiana for some perspective. Farm animals do not have watches.
Just because Indiana doesn't have DST now (for most of the state, anyway) doesn't mean they've always never had it. There was DST when I was growing up in the 70s, and they got rid of it long after agriculture was no longer the primary industry in Indiana.
Having grown up in Indiana farm country, I'm of the opinion that "DST because farmers" has always been a myth. One gets up with the sun no matter the time. You quit work when it's dark.
Oh, wait, that's not true, either. With the advent of electric lighting on vehicles about, oh, 100 years ago, lack of sun no longer need keep one from the fields. I recall many a late night that the farmer that owned the field next to us was out either tilling or harvesting, lights ablazin' on the front of the tractor or combine.
So we've eliminated the farmer myth, why do we have DST? Few like it, do I...follow the money?
The main justification for DST is that it saves energy. The actual evidence of this claim is rather mixed, although even reports that show that DST saved energy aren't necessarily finding that the reduced costs make up for the mere cost of having to switch clocks twice a year (which itself isn't particularly well-quantified).
The history of DST is distinct from agriculture, it was more strongly connected to factory work. It's easier to have every employee change their clock by an hour than change the schedule twice a year.
However, we've moved away from the need (mostly) for the potential energy savings, though perhaps for the wrong reasons (we work in offices and factories with little natural light). The remaining reason to keep it is to allow people access to daylight after their normal work hours. But this can be accomplished by shifting schedules. Move the standard start of work from 7 to 6:30, split the difference. And if that seems intractable, shift our time zones by 30 minutes and be done with it.
13 * 28 = 364 not 365. So you'd need an extra day every year and 2 extra days every 4 years.
What we really need to do is use some rockets to slightly slow down the rotation of the earth so that a day is exactly 1/360th of a year. All kinds of numbers divide evenly into 360 so that should make building a good calendar easy.
While it wouldn't exactly follow the lunar cycle as the parent mentions, there are already proposed calendars similar to what you mention[1]. Of course, with any calendar readjustment come just as many drawbacks, as the wiki entry mentions some.
I'm disappointed that this wiki page mentions no drawbacks to my plan to slow down the rotation of the earth. I've no idea what they would be, but I'm guessing that this might come with some negative repercussions.
In Northern areas, there's a lot of practical value that gets overlooked. In Boston, the sun is rising close to 5:00 AM as it is at the height of summer. Without daylight savings time, it would be rising at 4:00 AM. I think most people would rather have extended daylight late in the day than have all that extra sunlight wasted when we're sleeping.
The counter to that is -- well, let's always stick with daylight savings time then. That has problems of its own. For example, sunset is a little after 4:00 PM in Boston in late December. If we stuck with daylight savings time, it'd be a little after 3:00. That would pose risks for school children walking home, etc.
Yes, I realize that people in Fairbanks Alaska have it much worse and daylight savings doesn't fix the problem for them, but there are a lot of people who live in the northern parts of the lower 48 that benefit from the time shift.
> For example, sunset is a little after 4:00 PM in Boston in late December. If we stuck with daylight savings time, it'd be a little after 3:00.
This seems backwards. Sunset would be after 5 if they kept daylight savings.
I used to live in Boston, and I despised how early the sun would set. It made getting off of work demoralizing. I always liked the idea of just switching to Atlantic time. Whatever the case may be, I strongly value daylight later in the day rather than in the morning.
You're backwards. The problem with year-round daylight savings in Boston (which, personally, I'd prefer) is kids going to school in the dark in the winter. Boston's both relatively northernly and very far east in a timezone because eastern time wraps up the northeast-jutting coast of the US to avoid New England being in its own timezone. [Edit: It wouldn't be in its own timezone; it would be in Atlantic time, which is used in parts of Canada. But it would put Boston in a different timezone from NYC and other major east coast cities.]
DST's not really all that useful at either latitudes where the day length is relatively uniform throughout the year nor at latitudes that vary between more light than you know what to do with and dark in morning and evening no matter what.
It's really primarily useful when you have enough light for long summer evenings and winter days that are short but are still long enough that it makes sense to fine-tune sunrise and sunset relative to normal work and school times.
We actually contemplated (in the state legislature) moving to Atlantic time in Maine a few years ago. I'm glad they didn't because we have enough business barriers as it is without adding that into the mix, but it might not be bad if all of New England did it together.
> For example, sunset is a little after 4:00 PM in Boston in late December. If we stuck with daylight savings time, it'd be a little after 3:00
This is backwards. Sunset would be later, at about 5:15PM (the problem would be late sunrise in the morning). For instance, sunset on October 31 in Boston this year will be 5:40PM EDT, but on November 1 it will be 4:39 EST.
You did, however, demonstrate another fantastic reason to rid ourselves of changing our clocks: mass confusion twice a year :)
More than that; you're forgetting about locale specific DST rules. It is increasingly common for DST to be observed at different times in different countries. Then there are also places (such as Arizona) that don't observe DST at all as well.
This is a mess that can only be solved by isolating 'meeting' and 'appointment' times from local time. For local time you might specify X on date Y, but the software should, at the time of input, convert that to an actual hard time (in UTC).
The fun trick is that on the western edge of the Eastern time zone, kids have to travel to school in the dark. It's probably reasonable that we defer to population though.
I live in Atlanta. Central time starts about sixty miles west of me at the Alabama line. Sunrise was at 7:54 this morning. That means when I woke up at 7 there was no visible light.
The solution to this would be for Atlanta to be on Central time (which it actually was, historically) but that won't happen - time zone boundaries generally shift west over time, and this one overshot the mark.
Not that I would advocate confusing matters by changing the calendar again, but you just move the birthdays same as last time.
From Wikipedia: George Washington (February 22, 1732 [O.S. February 11, 1731] – December 14, 1799)
Notice the year is different. In the British Empire before 1752, March 25th was the first day of the year. March 24, 1751 was the day before March 25, 1752. Then September 2, 1752 was the day before September 14, 1752 The last day of 1752 was December 31, and the calendar has continued how we consider normal ever since.
The British custom of starting the tax year on April 6th survives as a relic of the old calendar (March 25th plus the missing 12 days in 1752).
For anyone interested in time zones, I had a terribly unproductive afternoon the day I started looking through both the time zone mailing list[1], and the raw zoneinfo files. I love the history that lies beneath all of the changes.
The Turkish change affected me over the weekend. The local mobile carriers didn't update their settings and thus my phone automatically updated to EEST. Fortunately my flight was much later in the day and it was rectified by that point.
Lots of events needs to be scheduled in local time. If your calendar app stores a given UTC timestamp for your meeting with a customer on friday at 5PM and the time zone rules database change inbetween, you're going to have an angry customer.
And what would meta-metadata about the datetime solve? What you're looking for is faster updates to timezone libraries. And for governments to stop being idiots — "I'm delaying DST because it inconveniences me", pah, what a load of garbage. It's a symptom of how much DST sucks. If anything, this couldve been a good occasion to repel DST in turkey.
If you stored it in the DB as "2015-10-30 17:00:00 SOMETIMEZONE" then it would be unambiguous when the event is going to happen. If you stored an UTC timestamp, well, then you'd get two different values depending on whether you had the updated tzdata or not when the value was entered and converted to a timestamp.
If you think this problem can be solved by declaring today's version of tzdata immutable and final, then I'm afraid you're not being realistic. Timezones, DST rules, country borders will change and always have.
Storing the timezone name does not work when the boundaries between timezones change. Best to store local time and location. http://fanf.livejournal.com/104586.html
> by declaring today's version of tzdata immutable and final
It doesn't have to be immutable and final, it can simply be versioned then :) cf what I said in my other reply, if you create a new timezone every time you change it, it seems you don't have that problem.
It is good enough. When converted to the local timezone, the library would know to offset the date properly - it just has to be told to do it. I don't see the problem.
Store the starting point for a meeting scheduled for October 30th, 2050, at 5pm local time in Pyongyang.
Are you sure the value of UTCunixtime("2050-10-30 17:00:00 Pyongyang") today will be correct in 2050? What if this record was created last year? (hint: the timezone was recently changed).
Remember, the meeting is supposed to happen at 17:00 local time on that day no matter what.
Ah, I understand better now. Though this wouldn't be a problem if timezone names weren't reused, right? eg. "2050-10-30 17:00:00 Pyongyang" would correspond to "2050-10-30 17:00:00 Pyongyang2" just fine.
It'd still be an issue, because people lose their minds when thinking about time zones. Example: .net XML serialization. The PM wanted to "do the right thing" and thus would encode all dates in XML with an offset determined by looking at some local setting. Hence the exact same code would produce a different XML document depending on the selected time zone.
They 'fixed' it by using a couple bits of the date to note if it was UTC or 'local'. But for a version or two, there was no way around corrupting data. The PM lamented the fact, saying "if only machines all had GPS, then we'd know the right offset to use", further demonstrating the lack of understanding.
Some folks just can't resist thinking in local time, instead of letting the dev handle time zones additionally.
Even the great tzinfo database is weird. Instead of using the names of time zones, it uses a random city. Which means if a time zone does split up in the future, you might end up with an incorrect timezone. (Like if I select Denver, but Denver switches to New Mountain Time, but my city doesn't.)
I'm sure there's no problem that can't be created by a sufficiently bad PM.
I think you can treat the name of the city as the name of the timezone. Seems like you'd have the same problem either way. If you used "Mountain Time" and then your city switches to "New Mountain Time" you still have the incorrect timezone.
Instead of cities it could use polygons on the surface of the earth, but that's starting to get complicated at that point.
I've always joked that the more I work with i18n and l10n the more I become a fan of one world language, currency, and time zone. I know that would be rife with its own problems but hey, an exhausted developer can dream.
Is it me or does it look like some countries / states are moving towards abolishing daylight savings? I hate to revisit this topic but I would love to see this horribly archaic system abolished ad infinitum.
All space time clocks may run at GMT+00 with no regional differences.
Actually we may remove time zones all together too. So the day time of 3pm will be different everywhere. For calendar months and seasons we already have it like that, in both hemispheres. The only issue is backward incompatibility with legacy movies, books who talk about breakfast at 8am. Similarly, a love song which talks about April/May being a sunny warm time sounds weird in southern hemipshere. Let's get rid of Roman legacy code in our civilization :)
Oh no, it's much worse than that. On Earth you can generally treat time as being the same speed everywhere. If you start a timer at T1 UTC and run it for a locally observed 60 seconds you can expect the current UTC time to be T1+60 seconds. In space relativistic effects stop being negligible and you might find that UTC time is T1+61 seconds.
We have clocks that are wrong all the time already, I'm not sure how that makes date time libraries worse. GPS satellites are in space, they have to deal with relativity effects, and mostly everything seems fine.
Or you can change the relative speed with which it tracks its time. Smearing is already used for additional seconds, it should be possible to be used here, too.
But GPS satellites have constant velocity so calculating this is pretty easy. For a future super probe that accelerates and decelerates and maybe passes through many different gravitational fields (giving a general relativity time dilation) and perhaps does so for many centuries, the possibility of error mounts up.
I'd vote for time being defined in terms of some universally observable phenomenon. Say the rate of cooling of the CMB. Anyone with a super spiffy radio telescope anywhere in the universe could then tell what time it is.
Removing time zones terrestially, while seeming attractive on the surface, generates more problems than it solves: http://qntm.org/abolish
There's a lot that could be improved with how we handle things like Daylight Savings Time today, but eliminating time zones is throwing the baby out with the bathwater.
This article was pretty thoroughly debunked last time it was linked here. It focuses on how we'd remove timezones and not actually offer alternatives to their most basic uses.
It seems attractive to me at first blush. However, with time zones, when you ask your associate on the other side of the world "what time is it there?", the implications of when you can expect communication is almost immediately. Having to ask "when do you get off work" seems a little more cumbersome to figure out all the following details.
But hey, we muddle through the current chaos, I'm sure we can muddle through any other chaos.
Or Imperial measurements in the U.S., or driving on the left in the Commonwealth countries, or non-Unicode encoding in Japan, or right-to-left writing in the Middle East. Whenever an agreement on anything is reached in most of the world, there's often some conversion benefits for whoever holds out signing up to it.
While we're, talking about changing time monitoring systems, can't we have 13 months with 28 days each? (and an extra day every 4 years added on to december?) :(
Simple things, but that would allow us to follow the lunar cycle.