311–320 of 321 posts
In this way, we can tell the exact time something happened in the past, no matter how timezones/DST changes, but we can also have future events stored according to people's expectations.
Earlier quoted context omitted.
well, technically the "funny" aspect I was talking about, was the things that happened once the meeting room booking has conflicted and two group of people clashed both claiming that their booking was more right (as opposed to "how funny this can happen" in the first place). It's also interesting that since this doesn't happen frequently enough it's usually hard to develop a good way to get out of it.
I think I'd resolve it by saying that any bookings made in a timezone that has changed its definition will be cancelled if the new definition causes the booking to conflict with another (including the case where two or more timezones have changed simultaneously: all involved bookings attached to changing timezones are cancelled). "The timezone you have used to define this booking has been altered, and the booking can…
Earlier quoted context omitted.
Oh, that's fun: "A change in the definition of a timezone has caused previously non-conflicting bookings to conflict."
Yep, time zones are lame and we’d be much better off if everyone just got used to saying the time in UTC. But then an “9 to 5” would become a “regular 8-hour shift” and be less fun to talk about, school might let out at 0300, and the times would vary when it’s dark / light out, which would probably be too much for the average joe to handle.
Earlier quoted context omitted.
That is an interesting fact I wasn't aware of. I have doubts about the actual relevance of this, though. e.g. Chinese seems (so far as I can tell) to have always used decimal numbering systems, making this essentially a clever counting trick.
"I had no idea this thing even existed but let me continue to tell you why it's inferior"
Earlier quoted context omitted.
Oh, that's fun: "A change in the definition of a timezone has caused previously non-conflicting bookings to conflict."
Yep, time zones are lame and we’d be much better off if everyone just got used to saying the time in UTC. But then an “9 to 5” would become a “regular 8-hour shift” and be less fun to talk about, school might let out at 0300, and the times would vary when it’s dark / light out, which would probably be too much for the average joe to handle.
Earlier quoted context omitted.
We spent weeks on this for our new conference calling app to determine when a user says "Setup a call at 10am for my group every week" that come October 29th 2018 the call takes place at 10am, not 9am following a DST change. After a heckuva lotta research and reading we determined that we needed to store the scheduled meeting time using two values; the local datetime and the desired timezone eg. scheduledAt: 2018-05-…
This kind of thing becomes a lot of fun when you're trying to schedule a regular international call between e.g. the US and the UK, where the offset in hours changes four times per year because their daylight saving adjustments are not simultaneous. When I say "becomes a lot of fun" what I actually mean is that this observation lets us understand very quickly that the problem is not generally solvable. One way or ano…
My side doesn't observe DST. The other side does. The border keeps different Summer and Winter hours.
Trying to figure out when I need to leave to make sure I get to the border during its open hours to get through, and then when I need to leave (in local time on the other side) to get back through during the open hours is an extremely tedious problem.
Worst part is crossing the border is just me driving South. My longitude doesn't really change.
Earlier quoted context omitted.
Yep, time zones are lame and we’d be much better off if everyone just got used to saying the time in UTC. But then an “9 to 5” would become a “regular 8-hour shift” and be less fun to talk about, school might let out at 0300, and the times would vary when it’s dark / light out, which would probably be too much for the average joe to handle.
Eh, people would keep saying 9-to-5 and post in Future-Reddit "TIL 9-to-5 jobs are called that because in the early 21st century 9am was defined as when the work-day started" or something else equally half-right.
Earlier quoted context omitted.
We spent weeks on this for our new conference calling app to determine when a user says "Setup a call at 10am for my group every week" that come October 29th 2018 the call takes place at 10am, not 9am following a DST change. After a heckuva lotta research and reading we determined that we needed to store the scheduled meeting time using two values; the local datetime and the desired timezone eg. scheduledAt: 2018-05-…
This kind of thing becomes a lot of fun when you're trying to schedule a regular international call between e.g. the US and the UK, where the offset in hours changes four times per year because their daylight saving adjustments are not simultaneous. When I say "becomes a lot of fun" what I actually mean is that this observation lets us understand very quickly that the problem is not generally solvable. One way or ano…
Time is an illusion.
Lunchtime doubly so.
— Douglas AdamsEarlier quoted context omitted.
Yep, time zones are lame and we’d be much better off if everyone just got used to saying the time in UTC. But then an “9 to 5” would become a “regular 8-hour shift” and be less fun to talk about, school might let out at 0300, and the times would vary when it’s dark / light out, which would probably be too much for the average joe to handle.
Everyone on UTC is really just useful for scheduling stuff internationally and just because of that, telling everyone to change their daily life, so you have it a bit easier, doesn't seem like the right plan. Additionally, timezones aren't really the big issue, it's more the changing of timezones due to DST or similar is what's causing the biggest issue. Getting rid of DST looks like a lot better solution for everyon…
In my country the train stops for one hour at the spring DST change and just waits for time to pass to account for the "missing" hour and not mess up the schedules by arriving one hour earlier.
So the article seems to imply you should store all timestamps as UTC (with an additional timezone string ID). But for events in the future that needs to happen on a specific "wall clock point in time", it might be better to actually store the yyyy-mm-dd hh:mm:ss as a string with a timezone next to it, because timezones can and do change often unpredictably. If you pre-calculate what "4.00pm next August 1st" is as a U…
Some timezones change twice a year. Seriously![1] A fellow engineer was responsible for the web front-end framework for dealing with time (back when we built it all here) and he spent months working through some of the strangest crap, some JS, some wierd crap humans dream up. Good example: you, user A, are in a TZ that switches biannually - at one point in the year you lose an hour, at another you experience an hour…
This sounds exactly like a line out of some Douglas Adams book. Which is perfectly fine as long as no one booking meetings on that app has read any of his books.