UTC Is Enough for Everyone, Right?
231–240 of 321 posts
Re: UTC Is Enough for Everyone, Right?
#232Re: UTC Is Enough for Everyone, Right?
#233"Physicists are still debating on whether or not time actually exists in the universe." I'm not aware of any physicists debating this. If time didn't exist, there wouldn't be a physical dimension for it, and everything would be at a fixed position in 3-dimensional space.
It's not necessarily the case. Maybe the universe is just an tangled graph of events. Maybe the dimensionality of spacetime only emerges as an asymptotic behavior of this graph and it breaks down in small scales. In this view time doesn't exist at a microscopic level.
Re: UTC Is Enough for Everyone, Right?
#234In my 20 years of working with software and distributed architectures, no problems have been harder than working with time zones and calendars. It is truly nightmarish stuff. I am convinced you could run a very profitable consultancy specializing in debugging date and time related problems in people's systems.
Re: UTC Is Enough for Everyone, Right?
#235Earlier 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…
very funny things happen when there is a shared physical resource e.g. a booked meeting room, and you have a bunch of people schedule meetings with different reference time zones.
ah, and if you think this creates havoc only for a the few weeks while the TZs are out of sync, remember that in the southern hemisphere DST is applied in "reverse"
Re: UTC Is Enough for Everyone, Right?
#236Earlier quoted context omitted.
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…
> [..] regularly scheduled meeting time specifically to the UK or to the US very funny things happen when there is a shared physical resource e.g. a booked meeting room, and you have a bunch of people schedule meetings with different reference time zones. ah, and if you think this creates havoc only for a the few weeks while the TZs are out of sync, remember that in the southern hemisphere DST is applied in "reverse"
Re: UTC Is Enough for Everyone, Right?
#237We’re going to need a new data type: spacetime
Re: UTC Is Enough for Everyone, Right?
#238Could you start making websites which are readable? Jumping icons, moving background, flickering colors, gray letters on colorful backgrounds - all that makes me hard to read... so I'm sorry, I'm not going to read that.
Re: UTC Is Enough for Everyone, Right?
#239Postgres have done a really good job here. It not only understands offsets (which most devs think are timezones) it also understands timezones. What's the difference? GMT-8 is an offset. America/New_York is a timezone. This becomes important when you want to schedule a meeting on the east coast of the USA in April - Europe and the US change DST on different dates. But if you tell postgres you want a time in a particu…
What's the point of unqualified offsets like that anyway? You either use UTC or a local time in the appropriate tz.
Re: UTC Is Enough for Everyone, Right?
#240Earlier quoted context omitted.
You also need to periodically compute the next event, but you can't do it too far in advance. You have to do it close enough to the event that that you can adjust to timezone definition changes. Hopefully you don't have to think about leap seconds.
Why would anybody schedule events in local time to happen on leap seconds?