It’s only bad when used incorrectly. Just store time in UTC and convert it to timezone of your setting to present it. Most modern languages offer a library that makes it just one more line of code. Not only it’s then clear and unambiguous, it supports all timezones.
bingo. Timezones became easier when I learned that all apps and databases should have all times be in UTC. Let the UI do it’s thing and accept local time and convert it, and vis versa.
Yeah, timestamps should always be stored in UTC, but actual planning of anything needs to be conscious of local time zones, including daylight savings. Coming up with a description of when a place is open in local time might be simple when described in local time but clunkier in UTC when accounting for daylight savings, local holidays, etc.
The Solution: Space mirrors! A series of mirrors in space would rotate to keep the entire planet under a single time zone. A perfect global time system is born!
Sounds like a great idea! With the best of intentions. What could possibly go wrong?
Alternatively, we have this arbitrary standard of 9am means morning, if we share a single universal time, different places would just have a different arbitrary time being the “morning” instead.
i would aruge that the arbitrary factor of “9am being morning” is entirely to do with the fact that morning is actually a solar time phenomenon, whereas global time does not have the concept of morning, since it is merely imitating the local solar time.
Local solar time being the literal point in the sky that the sun is in.
It gets even funnier if we include people who aren’t “normal” I for one, consider noon to be morning.
We could keep the 0 hour as the “middle” of the night and 12 being the “middle” of the day (though I’m not sure if that’s really the sun’s high spot for the day for any places).
But with fully controlled mirrors, we could make it exactly 12 hours, so we could just then switch to the 0 hour being when the sun comes up.
It could have been worse. The romans had the day divided into 24 hours, like we do, but the hours varied in length so that from sunrise to sunset, you would always have 12 hours.
Imagine if that was the agreed upon time system, and we had to program that into computers.
It’s called temporal hour. Many cultures around the world had such a time system. Like in Japan they made clocks and watches that could tell temporal hours called wadokei.
I would truthfully and happily go back in time and tell people not to waste with the fucked up bullshit technology of the past. I mean Angular 1, what the hell was that? Twitter integration? Fuck you 2010. Zend Framework? You should be hanged. HANGED.
Oh, I see. Yeah I suppose it is, now that you point it out. It comes from:
.gov: the US government
.nih: the US National Institutes of Health
.nlm: the National Library of Medicine
.ncbi: the National Center for Biotechnology Information
But really, I only know it because it’s a very common host that comes up when you’re searching for published research papers. I just see “bunch of Ns .gov” and know it’s reliable.
Video is a lecture about how to think about dates and times, through the lens of a specific open source .NET library designed to aid with applying that thinking. It points out how most languages’ standard libraries really work against you, because they conflate different concepts. For example, an Instant (a specific point in time, globally recognised) and a LocalDateTime (a date and time in a way that is irrespective of your location—for example you might want your alarm to wake you at 8:00 am on weekdays, and still do that if you move to a different time zone), a ZonedDateTime (a date and time tied to a specific location—like if you want to say “the meeting starts at 10:00 am Oslo Time”), and an OffsetDateTime (a date and time tied to a specific UTC offset—which is not necessarily the same as a time zone, because “Oslo Time” is a time zone that doesn’t change, but its UTC offset might change if they go in or out of DST, or if a place decides to change, like how Samoa changed from UTC-11 to UTC+13 in 2011.
These are all subtly different concepts which are useful in different cases, but most libraries force you to use a single poorly-defined “DateTime” class. It’s easier and requires less thought, but is also much more likely to get you into trouble as a result, precisely because of that lack of thought, because it doesn’t let you make a clear distinction about what specifically it is.
His library is great for this, but it’s very worth thinking about what he’s talking about even if you don’t or can’t use it. As he says in wrapping up:
You may be stuck using poor frameworks, but you don’t have to be stuck using poor concepts. You can think of the bigger concepts and represent all the bits without having to write your own framework, without having to do all kinds of stuff, just be really, really clear in all your comments and documentation.