I think you really nailed it here. People who aren't "morning people" are viewed as lazy, strange, and unmotivated. And it's very frustrating to try to make people understand that I don't stay up until 3:00am every night and sleep until noon, or that I'm not lazy because I'm not flitting around the room like a humming bird the moment I get out of bed. It's like it's completely impossible to have this conversation because people are totally unwilling to see things in any other way.

Also, the early worm gets eaten.

Another issue is that it often makes sense for people that work together to be in the same place at the same time.

The implicit assumption that it is somehow morally better to get up early in the morning is very prevalent in Germany, too. I think it's a protestant thing, or at least a Christianity thing - getting up late in the morning implies sleeping in which implies laziness, which is a deadly sin. In fact, I remember listening to an interview with a neurologist (or a biologist whose focus was the nervous system), who said it was absurd to force children to get up as early in the morning as the adults, because for the first one or two lessons, their ability to learn would be impaired anyway.

There is one thing to be said, though, in favour of uniform working hours - it is that you do not need to worry about when your friends are free or working. During my Zivildienst (https://en.wikipedia.org/wiki/Zivildienst) I worked in a hospital in shift work. Working the early shift meant I could not go out the evening before, because I had to get up at 05:00, so I had get to bed early; working the late shift meant that I only got off work when it was already evening.

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 definitely agree that this is a major issue that we need to address.

That is, our schedule is not a biologically-based schedule. "Morning" (as defined by our society) is not the biological default.

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.

He was also the buttmunch that gave us daylight savings time.

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.

https://qntm.org/abolish

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.

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.

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.

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.

For some extra fun, the Navajo Nation observes DST, and they're _inside_ Arizona.

https://en.m.wikipedia.org/wiki/Daylight_saving_time

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.

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.

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?

I'm guessing OP doesn't mean 'presumed valid' but 'preferred in decisions' despite previous practice and ostensibly minority position..