Em 14/12/2017 14:14, Leyne, Sean escreveu: > > Separately, consider that calendar applications exchange times using UTC > offset contexts not time zone/region names. Why? Local Timezone UTC offsets > and DST rules are *variable*, UTC offsets are not. >
It's stored normalized to UTC, but the point in also store the region or offset is about to also record (to convert back when reading) the data as who stored it. It's the same as case-insensitive collation. People want case-insensitive searches, but want to store the data with proper case as entered. >>> 2 - Conf Calls/Webinars (no other events can occur in multiple time zones). >> In these cases, we schedule (set the start time) based on a current >> understanding of what the time difference would apply to all members of >> the conf calls/webinar. So, in this case mental math is required and can't >> be >> avoided. >> In a global world, you can only choose a hour good for your main audience, >> not all, but this is not the point. >> >> The point is about one needing to manually (or via application) need to know >> what will be the timezone offset of a future date. > > That is not a database issue, it is the reality of how meetings are scheduled > across timezones. (I have this problem when I setup calls to clients in > India, Singapore or Australia) > You say there is a problem, it's sure there may be ways to avoid it or to not make it worse. The PostgreSQL approach with conversions to session time zone seems very problematic. Should I also say that to make things work I should set my session time zone to +02:00 instead of -02:00? It's weird and crazy, but it's how it works. See it: https://stackoverflow.com/questions/47555028/postgresql-time-zones >> In Brazil, for example, this depends on non obvious factors, for example, >> carnival end date, which is difficult to calculate. Previously, it was even >> worse >> the DST planning dates. >> >> This year our politics was speculating to not start DST just days before the >> initial date. > > Let's discuss that example further. > > So, what do you expect the impact of the change to the DST would be for an > applications. > > - You (in BrasÃlia) setup a phone call/meeting, 6 months ago, for today at > 7am (Dec 12, 2017 == UTC -2) with customers in Mumbai (5:30pm -- UTC +5:30) > and Adelaide Australia ( 10:30pm -- UTC +10:30) 7am in UTC -2 => 9am in UTC+0 9am in UTC+0 => 2:30pm in UTC+5:30 9am in UTC+0 => 7:30pm in UTC+10:30 Am I making a mistake or you? > - Each of you have an initial common definition of the meeting time. > - Imagine that the Brazilian government decided on October 1st that, as of > December 1st, the entire country is changing to UTC = -3. > > What do you expect to happen to the meeting time? > > The only way that the both parties have the correct meeting times is if: > > 1- both parties have a timezone database which is exactly sync'd ... > 2- the meeting Date/Time is stored with offset == -2. > But normalized to UTC+0, so a change my TZ region in my TZ database does not change conversions for others or cause problems in PK/UNIQUE keys. > Yes, I realize that this would result your time of the meeting changing, that > is your problem -- blame your government -- but the change in would be > consistent for your entire schedule, but your customer would be unaffected. > Yes. Adriano ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
