[tz] New IANA-timezone support date/time library
mikeadouglass at gmail.com
Tue Feb 23 16:18:40 UTC 2021
On 2/22/21 16:55, Kerry Shetline via tz wrote:
> On 2021-02-22, at 14:25, Paul Gilmartin <PaulGBoulder at AIM.com> wrote:
>> But the "Help" link (<https://skyviewcafe.com/help/>) fails with 404.
I just clicked on that and I get
Cannot GET /help/
It's encrypted with Letsencrypt so something at the server end isn't
delivering the page
> The “Help” link is working now, so I’m not sure what the issue was at the time you clicked on it.
>> I don't know whether you've followed the "Kiev"/"Kyiv" debate on tz at iana.org.
>> But I was curious what skyviewcafe.com does about it.
> I read a little of that, but haven’t followed it. At least the pronunciation of Kyiv isn’t an issue! ;)
> My geographic data base finds the Ukrainian capital by either spelling, so that’s not a problem. I’m not sure if showing “Europe/Kyiv” in my interface would be confusing or not, since that’s not the existing IANA name for the associated timezone.
> Users are generally expected to click “Find”, and find cities by name, thus getting longitude, latitude, and timezone automatically without fussing with a manual selection, so the IANA names aren’t quite so important.
> I also intend to update my manual interface to make timezone selections by standard UTC offset, and then a list of zones in that offset, as the default way to make a manual timezone selection, with region/zone being a secondary option.
>> I tried to enter
>> "50°25'N 30°31'E". I learned:
>> o It's tedious to enter such coordinates digit-by-digit.
>> o I found no way to refresh the page with the coordinates entered.
> It’s definitely tedious compared to just looking up a city and getting lat/long automatically. But if one wants to enter info manually, I’m curious what you’d prefer as a means of input. The manual entry field also supports rolling digits up and down, which is a fun way to explore how the sky changes as you change latitude and longitude.
>> Tz, trying to pivot away from the debate, says that internal directory
>> and filenames should not be obvious to users. Thus, applications should
>> not show me "America", "Denver", or "Kiev”.
> I hadn’t really thought of those names like “America/New_York” as file names, but as names for timezones as abstract timezone entities. In fact, there is no “America/New_York” file in the tzdb. There’s a file named “northamerica”, and inside that file, a zone entry named "America/New_York”. Perhaps that’s still something a bit too rawly technical to be considered user-friendly, however.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tz