> Then one insanely morning person joins and wants to leave at 3:30 every day. Suddenly all of his scheduling preferences were presumed valid
Why wouldn't their preferences be presumed valid? It's as hard for the morning person to deal with night-person preferences as it's hard for a night person to deal with morning-person preferences.
(Disclaimer: I'm a morning person and I'm not American.)
I think it's because people think "morning person" is the default, and correct, way of being. And that not being a morning person makes you odd or lazy. So when someone comes in challenging late-friendly scheduling, they're assumed to be the correct one, and that the workplace has somehow been in error by allowing later schedules.
Perhaps "morning person" is the default because many people have families and children and whether or not they operate best in the morning or evening, they are forced to operate in the morning because that's when school time is scheduled (the children are at school) and the children are home in the evening (default family time). I'm wishing that someday we can get to more flexible schooling hours. I think if we want to change the "morning default position" then we need to address schooling defaults.
Schooling is definitely a major issue. My nephew has to be at school by 7:15 am. It’s absolutley asinine to believe that pre-teens and teens can be functional or able to actually learn anything at such an hour. Not to mention the fact that every school is different. His younger brother, for example doesn’t start school until nearl 9:00. And this is an elementary and a high school in the same district. It’s insane. So their mom has to figure out how to get them to school a vastly different times, then figure out how to make it to work at a reasonable time given her schedule.
I definitely agree that this is a major issue that we need to address.
This is slowly changing. Here in Seattle we just went through a major shift where (most) public elementary schools start early, and the middle/highschool kids shift later.
But morning really is the default; it's our biological default. Most people wake up in the morning and go to bed at night naturally. Many people have small children, good luck remaining a night person with a 1 year old in the house. There are real reasons here, it's not just some arbitrary decision.
Grades in primary and secondary school jump significantly if you push start times back from 8 AM to more like 10 AM. It may be the biological default to wake up in the morning, but there's absolutely nothing that says that peak performance should be reached the instant you wake up. If anything, I'd expect exactly the opposite! It takes time to get caches warmed, adjust biochemistry away from resting levels and toward operational levels, and get dumb maintenance tasks (breakfast, travel to workplace, "milk the cows") out of the way and move to higher-value and more complex activities (hunting, crafting, socialization). Until you do those things you're not going to be operating well, and many early-morning tasks wouldn't require peak performance and optimizations for an early peak would be wasted. I'd also expect intellectual pursuits to be more strongly affected; you need to be able to not get eaten by a tiger at absolutely any time, but you can choose when to sit down and start knapping flint or talking to people, which means you have more freedom and reward when optimizing the timing of peak performance on intellectual tasks.
Sure, but you're quibbling over an hour here or there. When people use the term "night person" they don't mean someone who wakes up at e.g. 8 instead of 7, we're talking about pushing back work by many hours, which just isn't possible for most people without a much shorter work day (I'm ok with that!)
Without electrical lighting and such, I'd agree. Sleep not long after sundown, a mid-night period of wakefulness, wake up for the day around sunrise. Ever since I can remember, my own default is to maintain activity late into the night, and then sleep as close to 8 or 9 hours as I'm permitted. Granted, that's a little rough if my 3 year old happens to wake up at 7:30, but 8:30 or 9 is pretty common for him; at 1, he often slept until 10, after being put to bed at 8pm.
8:30 - 10:00 seems to be the time range that I'll be ready to get up, when left to my own schedule. It's usually 2-3 hours after I wake up that I'm really ready to jump into a heavy project. The person who wakes up at 6 is right on target to start working, if they come in at 8. Me, I always feel like I could've used a couple more hours of sleep, even if I went to bed at 10pm the night before.
But DST is in summer, isn't it? At least that is what I have been told: In summer, days are so long and start so early that we might as well move the whole day back by an hour, so get up early, finish work early and still have a couple of hours of daylight left.
Full disclosure: I am not a fan of DST, but I do not expect the current situation to change. In Europe, almost(?) all countries use it, so if just Germany (where I live) abolished DST, we would be out of sync with the rest of Europe for half of the year. Dealing with dates and times as a programmer is already confusing enough; if DST was to go, all countries would have to drop it simultaneously, or else the resulting patchwork would be too much of a pain. And I do not see that happening anytime soon.
DST is the civil equivalent of changing the behavior of some electronic hardware by doubling the clock signal instead of reprogramming and re-flashing the firmware. It's simple to do, but is also stupid and inefficient, and causes a lot of obscure unintended consequences later on. I'd actually be fine with converting all time and date records, all calendars, and all clocks to integer Julian Day Number, plus the integer number of milliseconds since mean solar noon at the Prime Meridian, plus another numeric field for greater precision, because there is an enormous advantage to not doing stupid tricks with clocks and time zones. Just count.
You do this at the expense of a huge amount of practical day-to-day functionality of time. Most people want times to be at least roughly synchronised with their day, and would rightly object to your system in the strongest possible terms.
Your link states that UTC is the international standard. Maybe for humans.
Unix time can represent roughly from 1902 to 2038 in 32 bits. That's the usual intermediary between the clusterfork of records in zoneinfo. To convert between time zones, you convert to the simple second count of Unix time, then convert to the target zone.
Much easier to store the time as the simple count and just make the UI do the work to display it in some user-friendly fashion. When the machines communicate to each other, there is no confusion, because they do not carry any assumption baggage regarding time.
We really need to fix time representation before 2038. Julian day plus second count is a decent intermediate step to a time representation that is agnostic to the cycles and orbits of specific planets. The least disruptive end game is probably a 64-bit integer representing a simple count of the number of milliseconds elapsed since the Julian Day epoch.
That would make now about 212383579680000, and we'd have until 9223372036854775807, or about 292 million years from now, to even decide whether to go another 292 million years by making it an unsigned int, or just expand it out to 128 bits, because chip architectures have been able to handle that much for 292 million years already.
The simple count is rather easy to convert into a human readable time. Subtract an epoch constant, then modulo by some cycle-length constants. Adjust by a custom rule set if necessary.
Besides that, why would I want to call Uncle Steve in Melbourne? Why couldn't I just send an asynchronous message to him? That asynchronous message can even include metadata about when I am available for synchronous communications. So yeah, I can "publish my 'waking hours'", as summarily dismissed by that apologia for time zones. I don't know when that was written, but now that every phone can be a computer, as well as a pocketwatch and personal calendar, the built-in assumptions that were necessary beforehand are no longer required.
I don't need to know that people are typically awake in a safe range between 9 AM and 9 PM as expressed in their local time zone. I don't really even need to know when they'll be awake to pick up. I can tell the computer assistant to give their user a message, and the assistant might or might not sound an audible alert that the user has new messages. I don't even really need to publish my own waking hours. If I don't care about that aspect of my privacy, I can let my computer assistant tell other computer assistants when its user is typically receptive to synchronous communication requests, based on usage history. It can advertise my "online" status for me, or lie about it for me, such as if I tell it to say I'm "away", but I'm actually on my phone, playing a few levels of Skinnerbox 5: Revenge of the Lootbox.
> Unix time can represent roughly from 1902 to 2038 in 32 bits.
Uh, several systems have already switched to a 64 bit timestamp that should last for a while. I am relatively certain that OpenBSD and NetBSD have done it, and I vaguely remember Linux doing that, too, but that might be a vague memory or wishful thinking. Other systems probably have switched, too.
That's fine; better than nothing. It still represents times within the span of human history as negative numbers, which sometimes leads to certain kinds of bugs.
Ideally, I'd never have to work with a negative date-time number, because someone always seems to want to check if t > 0 somewhere, and there's always a reason why t could plausibly be a valid negative. Or maybe someone picked some negative t as a sentinel value, and then left the company before I ever got a chance to slap them.
Julian Day is the only kind of time that has never insulted my delicate sensibilities in some way. Maybe that's intrinsic to the type, or maybe it's because those who chose to use it have never done stupid things with time (that I could see).
Most of the time (pun not intended), I do not need to worry about the time or date. But on a few occasions I had to, and it gave me a headache every time.
One time (again, pun not intended!), I helped one of our automation engineers who had somehow found out that I know the C programming language and asked me to help him with a problem he was facing: He wanted/needed an input gadget that would allow a worker at the customer site to schedule the cleaning process of the automated machinery in terms of "tomorrow at 3:15am". And then a process had to calculate how far that moment was in the future, sleep for the corresponding duration, then wake up and the the machines to get clean. Except that it had to work across the beginning and ending of DST. Which was not super hard in itself, you either add or subtract an hour from/to the duration you wait, but how do we figure out when the change between DST and normal time occurs? Well, turns out in Germany[0] DST begins on the last Sunday in March at 03:00am (the clock is set to 02:00am) and ends on the last Sunday in October at 02:00am (the clock is set to 03:00am). If all you have is the C standard library (C89!), figuring out if it is the last Sunday of a certain month is surprisingly annoying. Not difficult, but very, very tedious. That made me appreciate the simplicity of C's time_t like no other experience in my life. And I just scratched the tip of the iceberg, with nail file. I can imagine how much fun it gets when different timezones come into play, or divergent definitions of when DST begins and ends.
Your idea of Julian day + millisecond offset sounds beautiful. But I fear it will meet the same enthusiasm as my proposal to convert the metric system from 10^3 to 2^10, i.e. make one kilogram 1024 grams, a metric ton would be 1048576 gram, and so forth.
[0] And probably a lot of other places, but not all of them, because then it would be sorta-kinda consistent, and we cannot have any of that.
In areas that are arguably Europe, it looks like Iceland, Kaliningrad Oblast, and Belarus are the places that stick out.
I'm in California; most of Arizona is permanently in daylight savings, and we work with a lot of developers in China and India, which don't observe it. It certainly complicates things, sometimes.
I've done work on my product's logging subsystem before, and especially bugs with recorded times. Dealing with different DST rules is a mess.
> if DST was to go, all countries would have to drop it simultaneously, or else the resulting patchwork would be too much of a pain
There are already countless exceptions to DST and people seem to be doing fine. E.g. in Australia there are two regions in the same time zone where only one has DST, meaning they are out of sync for half the year.
As someone who lives in Arizona myself, it is a bit strange to have (virtually) the rest of the world change their clocks without us... makes scheduling remote meetings difficult, if nothing else. (On the other hand, we don't have to worry about changing our clocks in the first place, so there's that?)
For some extra fun, the Navajo Nation observes DST, and they're _inside_ Arizona.
Why do you believe Ben Franklin had anything to do with daylight saving time? The only thing I've ever seen by him in regards to DST roundly satirized the idea.
He wrote a paper (humorously) suggesting that Parisians would save on candle wax if they got out of bed earlier. Apparently Germany missed the humor when they pushed the clocks back in WW1 to save lamp oil.
It is possible that DST would have happened without Franklin, but I blame him anyway, because I never liked his sanctimonious attitude toward waking up early.
Context is important. You should read about why those two (completely unrelated) things came about when they did.
For example, there was a period of history where it was much safer to drink beer all day instead of water. Without context, that sounds like a really bad idea.
To make a long story short, it was because you boil the wort when you make beer, and the kinds of beers that people drank all day were small beers and session ales, with lower alcohol content (and cheaper to buy).
Those things actually are related. Franklin proposed that Parisians could save on candle wax by getting out of bed earlier, as a joke. Nobody actually changed a clock until WW1 when Germany did it to save lamp oil.
Franklin likely promoted the lark lifestyle only because he was one, rather than from any real evidence of objective superiority. He participated in a business group that looked at successful businesses with an aim to emulate their practices. It is possible that his advice to work early was just cargo culting, in following with a long line of sanctimonious lark philosophers that painted their owl counterparts as slothful or lazy.
Standard business hours favor being a lark because those are lark hours! And then they have the nerve to be all chipper and cheerful every morning, at a time when every decent owl would prefer to be getting one last REM cycle in. How do you think they'd like it if we made them stay up past midnight every day?
Why wouldn't their preferences be presumed valid? If I read the story right, there was one morning person and several night people. Why should the one person's preferences be presumed more valid than the several persons' preferences?
I think they meant more valid than the others. But if most people on the team are night person schedules, it should be on the morning person to adapt more.
Why wouldn't their preferences be presumed valid? It's as hard for the morning person to deal with night-person preferences as it's hard for a night person to deal with morning-person preferences.
(Disclaimer: I'm a morning person and I'm not American.)