INI website uses locale-specific times #77
Comments
|
Hmmm...changing from looking up or otherwise converting from Pacific time to looking up or converting from UTC time seems to accomplish little except that UTC has the word Universal in the name. Maybe thats the point? I think as long as all posted times a) clearly indicate the time zone in which they are specified and b) use that time zone consistently throughout our logistics artifacts, that is the best we can do. As an aside, it could be worth adding a clock to the INI web site pages (kinda like I did in upper-right corner on this site) that is guaranteed to show the correct/current time (in the INI adopted zone -- which appears to be leaning heavily towards PDT) regardless of where in the world the browser is actually running. |
|
I suppose another option is to post all times in both PDT and UTC. |
|
Sorry, but I think you have completely missed the point. Pacific Time does not mean anything to most people in the world, nor probably to most in the English-speaking world outside North America. People who are aware that there are different timezones around the world will almost certainly know what their UTC-offset is. I realise that this is not deliberate, but using it gives the impression that this initiative is only for those for whom Pacific Time is familiar. I suggest: All times should have a TZ indicator, and should be posted in UTC as a minimum. |
|
As long as UTC is present, I have a hard time seeing it being exclusionary. I have a hard time seeing the use of that term in this PR as anything other than diversionary. |
|
I think you are still missing the point. Why are local times only shown in the PT locale? How would you feel if all times were in NZST (for example)? |
Like I'd need to do a little googling to learn how ot convert NZST (posted times) to PDT (my local time zone). |
|
The question still remains: why is Pacific Time treated differently from all other TZ? What does it mean for me if I am in a different TZ? Please try to see this from the point of view of someone whose timezone is different from yours. |
|
UTC is a different timezone from mine. I'm in EST/EDT and I never once asked for them to be changed. Mail programs are pretty good these days. :) Beyond that, my comment above still stands for m3e. |
✋🏽 I'm a software developer who has dealt with the timezone problem many times, yet I still haven't memorized my UTC-offset. I hate to think that's a failing on my part, but rather that I'm used to having websites automatically convert timezones for me or just googling when I need to do a conversion. I would propose having a programmatic way for the website to derive a user's local timezone and show that, while also putting the UTC time in parentheses as a fallback. |
While I think that is relatively easy to do. I think I do something similar here which displays the time in Chicago (the TZ in which a virtual event was being managed) regardless (hopefully) of where the browser is actually executing in the world. The challenge, however, is that one will not stumble into posted dates/times from INI only through a web browser on an INI web page. I think they get copied, re-posted, etc. in a number of different places for which have a smart web page will have no effect. And, like you, I don't know my UTC offset either. And, even if I did, I wouldn't know it when I was on travel outside my home TZ either. I know my height in feet and inches and weight in pounds too. I don't know them in meters and kilograms. I have to convert 😉 |
|
No-one has answered my question: why are times quoted in Pacific Time? |
|
Is this the web page you are concerned about:
https://inclusivenaming.org/calendar/ ?
Ed
…On Tue, Sep 14, 2021 at 2:09 PM sebbASF ***@***.***> wrote:
No-one has answered my question: why are times quoted in Pacific Time?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#77 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AALDI2BDRPDELWFFD33DNJDUB6MU7ANCNFSM5DMUWZKQ>
.
|
|
That is but one of the pages that uses or assumes PT. For example: Also used on mailing lists: |
|
Got it. I'm sort of looking at the space over which the problem is
solvable.
On other projects, I've used a bit of magic to cause the page to display in
the local timezone of the viewer.
We can do that for pages on the site. If the embedded google calendar is
an issue, I'm not sure we have much control over that (though it could be
investigated).
Ed
…On Tue, Sep 14, 2021 at 3:16 PM sebbASF ***@***.***> wrote:
That is but one of the pages that uses or assumes PT.
For example:
https://inclusivenaming.org
https://inclusivenaming.org/participate/
Also used on mailing lists:
https://groups.google.com/g/inclusivenaming/c/wEclk6uyQWM (no TZ
provided).
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#77 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AALDI2E3P5PFHE4PBLMPGX3UB6UQFANCNFSM5DMUWZKQ>
.
|
|
@sebbASF -- Thanks for opening this. I'll take a look. |
|
I agree that it is better to choose the TZ to match the browser rather than fixing it to a random value such as PT. The alternative is to always use UTC. Please ensure that the TZ is clearly specified whatever is chosen. Note also that date formats are different for the US compared with most of the rest of the English-speaking world. |
|
@sebbASF ... happy to get us to a fix... but UTC is no less random to me
and most folks I deal with outside EU than PT or IST... fixed TZes will be
completely opaque to most of the world no matter which one you pick.
The javascript magic I use for TZs (if someone would like to pull that
thread, here's the entry point I used on another project:
https://github.com/networkservicemesh/site/blob/92c58d3099e9eec3f70829b9cb2ed463f6f7551e/assets/js/app.js#L35-L45
).
also has tools for handling the date issue as well. I live in the US, but
personally prefer ISO 8601 formatted dates (YYYY-MM-DD) because they sort
correctly :) I would like to believe that ISO 8601 dates are universally
readable globally... but I strongly suspect that's wishful thinking on my
part in favor of my preferred solution :)
I generally when using the javascrip tricks will insert the dates in the
site in the fundamental timezone I can reliably get right (I am *terrible*
at TZ translation and for me parochially that's usually PT... but I
understand that's *just* me) and then the javascript handles the
translation to
the local timezone of the viewer.
I originally did it for virtual event schedules, because I fundamentally
believe you have zero chance of even getting your speakers to turn up at
the right time reliably with an unfamiliar TZ, much less your audience :)
Ed
…On Tue, Sep 14, 2021 at 4:49 PM sebbASF ***@***.***> wrote:
I agree that it is better to choose the TZ to match the browser rather
than fixing it to a random value such as PT.
The alternative is to always use UTC.
That will be OK even if the browser has a different view of the TZ from
its operator.
Please ensure that the TZ is clearly specified whatever is chosen.
Note also that date formats are different for the US compared with most of
the rest of the English-speaking world.
The US uses mm/dd(/yyyy) the rest of use dd/mm(/yyyy). This can also be a
source of confusion.
I think the calendar is problematic in this regard.
Better to use yyyy-mm-dd or MMM dd and dd MMM.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#77 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AALDI2HEQX5NA52ZF5QPFNLUB67PNANCNFSM5DMUWZKQ>
.
|
|
The point about UTC is that it is not tied to a particular country, and it does not have DST. The choice of PT favours West Coast NA residents over all others. Whereas UTC does not favour any geographical area. |
|
As to ISO dates, AFAIK no-one uses yyyy-dd-mm so the format is unambiguous. Another issue with local timezones is that the abbreviations are not all unique. |
|
Definitely true for the three character timezones. Generally I get best
results with IANA timezones.
Ed
…On Tue, Sep 14, 2021 at 6:05 PM sebbASF ***@***.***> wrote:
As to ISO dates, AFAIK no-one uses yyyy-dd-mm so the format is unambiguous.
Another issue with local timezones is that the abbreviations are not all
unique.
There are multiple meanings for:
ACT, ADT, AMT, AST, BST, CST etc.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#77 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AALDI2ANY3UQKMRJONSWDOLUB7IKNANCNFSM5DMUWZKQ>
.
|
|
@sebbASF - I think this will fix the times on the website:
inclusivenaming/website#103
You can see the preview here:
https://deploy-preview-103--inclusivenaming.netlify.app/
and here:
https://deploy-preview-103--inclusivenaming.netlify.app/participate/
which for me render to my local TZ (I'm hoping that's true for everyone
else too :) ).
Ed
…On Tue, Sep 14, 2021 at 6:28 PM Ed Warnicke ***@***.***> wrote:
Definitely true for the three character timezones. Generally I get best
results with IANA timezones.
Ed
On Tue, Sep 14, 2021 at 6:05 PM sebbASF ***@***.***> wrote:
> As to ISO dates, AFAIK no-one uses yyyy-dd-mm so the format is
> unambiguous.
>
> Another issue with local timezones is that the abbreviations are not all
> unique.
> There are multiple meanings for:
> ACT, ADT, AMT, AST, BST, CST etc.
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#77 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AALDI2ANY3UQKMRJONSWDOLUB7IKNANCNFSM5DMUWZKQ>
> .
>
|
|
At first glance it looks OK; I see a time in my local zone. However, I have just realised that there is a problem for Locales with DST: I think the issue is that the meeting time is defined in PT rather than UTC. |
|
When the US changes to/from daylight savings time, the meeting time changes between 16:30UTC and 17:30UTC. So converting to UTC is wrong. Saying that the meeting times will change is more than just a "fix the website" issue. I think this should be closed now, and if you want meetings to be the same in UTC, open a new non-website issue or discuss within the org. |
|
@sebbASF This is why the javascript code uses IANA Timezones, not UTC offsets. UTC offsets are not timezones. Whatever timezone the meeting is defined in, this should translate to the currently correct local time for users. That said, it may be of utility to provide a further refinement to provide the meeting time in the timezone of definition in parenthesis so folks who are putting items into their calendars can enter it in the timezone of definition. For example, I grew up in Indiana and lived in Arizona (two US states that do not do DST)... and the local time of meetings defined in DST timezones moved when DST changed. If I simply entered meetings in my local tz, they would be wrong eventually. Entering them in the tz of meeting origin fixed that. Thoughts? |
|
Also: DST is quite prevalent globally but sadly not very consistent... (another reason IANA is a better choice for TZ handling than UTC offsets). I'm a huge fan of ISO 8601... but its best understood as a standard for defining single specific points in time, not recurring meeting times. |
|
INI leadership seems to be all based in the PT zone. Were they based in Indiana or Arizona, I suspect they would have used a local meeting time which would have corresponded to a fixed UTC time. It should be possible to choose a fixed UTC meeting time and publish that as the official time. When that is translated into (say) PT local time, it will appear as either PST or PDT; the reader will hopefully be aware when they are close to the changeover date and can make the necessary adjustment. The reverse does not work. |
|
"I suspect they would have..." Okay, you're certainly welcome to do so.
Perhaps. But this issue is not the place to do that. |
|
@sebbASF The problem is actually completely independent of which TZ the meeting time is rooted in. I've been looking at calendars for example, to see how they represent times (since I anticipate folks wanting to put meetings into their calendars based on what's on the website). Turns out... they are all conflating offsets and timezones in most unhelpful ways. If I take for example Google calendar: Each of those is a timezone with a DST involved. Each of those displays the current GMT offset. All of them correct for DST for the selected offset (meaning a recurring event is not always at the displayed offset). I do not appear to have an obvious way to enter a calendar event at a GMT offset without binding it to a timezone. What I'm trying to figure out now is how to get usable representations of timezones folks can use in their calendars. I had fond hopes that IANA times would help here, but sadly, they are not what is being used in the calendar apps. Intl.DateTimeFormat does have a timeZoneName option that can take 'short' or 'long'... with long resulting in things like 'Pacific Standard Time' (at least in my locale). That appears to be useful in my locale... but I need to see a bit if its useful in other locales. I don't think the INI leadership is necessarily rooted in PT. I'm currently in CST (and have never lived long term in PST), @justaugustus is in EST (most of the time), a number of others are scattered across a wide assortment of timezones. I have in the course of the last decade lived in a large number of different TZs (I was nomadic for three years). My experience has been the following (YMMV):
I'm personally very very bad at TZ translation, I can only really manage the timezone I am in and one other, so I'm quite sympathetic and willing to do work to make the situation better (see the PR). |
|
I think your note points to what might be a more complete solution: have a link that gives you back an ICS file for the calendar. Most of the ones I've seen have "g-calendar" and "ms outlook" format, which are the same but have a different content-type HTTP header I think. Of course, then we get to argue about calendaring apps. :( I think you did a great job converting to local-time. Perhaps add a new PR to convert to UTC; or don't bother. |
The INI website uses locale-specific times for meetings etc.
It would be more inclusive to use UTC throughout in case there are people who live far from the locale who would like to participate. Readers should not have to look up what Pacific Time means to them.
The text was updated successfully, but these errors were encountered: