Mailing List Archive

On Sun, 29 Aug 2021 19:49:19 -0700 (PDT), "hongy...@gmail.com"
<hongyi.zhao@gmail.com> declaimed the following:

>On Ubuntu 20.04.2 LTS, I use the [recent2](https://github.com/dotslash/recent2/blob/master/recent2.py) to log and query my bash history, which uses a sqlite3 database to store the history information. The `datetime` of running a command is inserted in the sqlite3 database with [a `unixepoch` format](https://github.com/dotslash/recent2/blob/f1018aee228c710cc7d1b8b93bc0228791a54563/recent2.py#L45), and it will be converted into `localtime` accordingly when retrieved and displayed later.
>

As I read it, it is interpreting whatever value was provided as
UNIXEPOCH when storing the value -- but stores it as an ISO date/time
string! https://www.sqlite.org/lang_datefunc.html

2004-08-19 18:51:06
2021-08-30 22:28:58

I can't see anything in that code listing that explicitly manipulates
the date/time when fetched for output. Nor do I see the connection
specifying Python adapter usage:
https://docs.python.org/3/library/sqlite3.html#default-adapters-and-converters
so I'd expect the output to be in ISO UTC format; the native result of
using SQLite3's datetime()..

"""
if not args.hide_time:
cmd_time = row_dict["command_dt"]
if args.time_first:
print(f'{Term.YELLOW}{cmd_time}{Term.ENDC}
{colored_cmd}')
else:
padded_cmd = pad(raw_text=row_dict['command'],
print_text=colored_cmd)
print(f'{padded_cmd} # rtime@
{Term.YELLOW}{cmd_time}{Term.ENDC}')
"""
>But I found that it did not perform the correct conversion according to the time zone setting on the machine, as shown below:
>```shell
>werner@X10DAi-00:~$ rm 222222222222222222
>rm: cannot remove '222222222222222222': No such file or directory
>werner@X10DAi-00:~$ recent -fo -w . 2222222222222
>rm 222222222222222222 # rtime@ 2021-08-29 10:57:13
>werner@X10DAi-00:~$ date
>Sun 29 Aug 2021 06:57:22 PM CST
>```

Might have helped to mention you were in China... To me, CST is North
America Central Standard Time (and I'd have expected this time of year to
see CDT - Central Daylight Time)... That led me on a weird meaningless side
track...

What documentation do you have that says it will display the date/time
in local timezone? (The README appears to be incorrect -- the utility logs
unix epoch [UTC seconds since 1970] AS ISO UTC string).

sqlite> select datetime(1092941466, 'unixepoch');
2004-08-19 18:51:06
sqlite> select datetime(1092941466, 'unixepoch', 'localtime');
2004-08-19 14:51:06
sqlite>
sqlite> select datetime('now', 'localtime');
2021-08-30 18:50:19
sqlite> select datetime('now');
2021-08-30 22:50:32
sqlite>

I'm in EDT (Eastern Daylight Time) -- so 4 hours behind UTC.


--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

--
https://mail.python.org/mailman/listinfo/python-list

On 31/08/2021 11.07, Dennis Lee Bieber wrote:
> On Sun, 29 Aug 2021 19:49:19 -0700 (PDT), "hongy...@gmail.com"
> <hongyi.zhao@gmail.com> declaimed the following:
...

> Might have helped to mention you were in China... To me, CST is North
> America Central Standard Time (and I'd have expected this time of year to
> see CDT - Central Daylight Time)... That led me on a weird meaningless side
> track...
...

> I'm in EDT (Eastern Daylight Time) -- so 4 hours behind UTC.


Which is correct?

CST in China
https://www.timeanddate.com/time/zones/cst-china

CST in North America
https://www.timeanddate.com/time/zones/cst

and not to mention Cuba
https://www.timeanddate.com/time/zones/


«Time zones are often represented by alphabetic abbreviations such as
"EST", "WST", and "CST", but these are not part of the international
time and date standard ISO 8601 and their use as sole designator for a
time zone is discouraged. Such designations can be ambiguous; for
example, "CST" can mean China Standard Time (UTC+8), Cuba Standard Time
(UTC?5), and (North American) Central Standard Time (UTC?6), and it is
also a widely used variant of ACST (Australian Central Standard Time,
UTC+9:30). Such designations predate both ISO 8601 and the internet era;
in an earlier era, they were sufficiently unambiguous for many practical
uses within a national context (for example, in railway timetables and
business correspondence), but their ambiguity explains their deprecation
in the internet era, when communications more often cannot rely on
implicit geographic context to supply part of the meaning.»
https://en.wikipedia.org/wiki/List_of_time_zone_abbreviations


This is why ISO8601 uses the ±HH:MM numeric suffix to designate a local
time-zone (cf UTC - or as we used to say in the UK, "GMT", and in the
military, "Zulu").


Most of us know about ISO8601 formatting, even if we think of it as
something like the way Unix-time is expressed, rather than it being an
international standard.

Few are aware that "8601" has been extended to cover less-obvious dates,
times, and durations.

For example, do you know that today is (said to be) "the last day of
winter"? Assuming you, dear reader, are in the northern hemisphere,
indeed are living in a temperate zone (cf the tropics or closer to one
of the poles), you reacted by exclaiming "what!?".

Thus, one of the 8601 "extensions" deals with the idea that climatic
seasons have meaning to locations within a narrow range of latitudes,
and that they are six-month inverses between the earth's hemispheres.

So, you couldn't understand/didn't believe me - yet I am completely correct.
(as always - cough, splutter, snort...)

Welcome to the last day of (what may be) your summer!

These things can be tricky...
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list

On Tuesday, August 31, 2021 at 7:55:51 AM UTC+8, Dennis Lee Bieber wrote:
> On Sun, 29 Aug 2021 19:49:19 -0700 (PDT), "hongy...@gmail.com"
> <hongy...@gmail.com> declaimed the following:
> >On Ubuntu 20.04.2 LTS, I use the [recent2](https://github.com/dotslash/recent2/blob/master/recent2.py) to log and query my bash history, which uses a sqlite3 database to store the history information. The `datetime` of running a command is inserted in the sqlite3 database with [a `unixepoch` format](https://github.com/dotslash/recent2/blob/f1018aee228c710cc7d1b8b93bc0228791a54563/recent2.py#L45), and it will be converted into `localtime` accordingly when retrieved and displayed later.
> >
> As I read it, it is interpreting whatever value was provided as
> UNIXEPOCH when storing the value -- but stores it as an ISO date/time
> string! https://www.sqlite.org/lang_datefunc.html
>
> sqlite> select datetime(1092941466, 'unixepoch');
> 2004-08-19 18:51:06
> sqlite>
> sqlite> select datetime('now');
> 2021-08-30 22:28:58
> sqlite>
>
> I can't see anything in that code listing that explicitly manipulates
> the date/time when fetched for output. Nor do I see the connection
> specifying Python adapter usage:
> https://docs.python.org/3/library/sqlite3.html#default-adapters-and-converters
> so I'd expect the output to be in ISO UTC format; the native result of
> using SQLite3's datetime()..
>
> """
> if not args.hide_time:
> cmd_time = row_dict["command_dt"]

Thank you very much. Based on your above comments and the discussion on <https://stackoverflow.com/questions/4770297/convert-utc-datetime-string-to-local-datetime>, I fixed this problem by the following method:

# Install and import some necessary packages:
from datetime import datetime
# pip install python-dateutil
from dateutil import tz


Then use the following codes to do the trick:

from_zone = tz.tzutc()
to_zone = tz.tzlocal()
cmd_time = row_dict["command_dt"]
cmd_time = datetime.strptime(cmd_time, '%Y-%m-%d %H:%M:%S').replace(tzinfo=from_zone).astimezone(to_zone).strftime("%Y-%m-%d %H:%M:%S")


Best, Hongyi

> if args.time_first:
> print(f'{Term.YELLOW}{cmd_time}{Term.ENDC}
> {colored_cmd}')
> else:
> padded_cmd = pad(raw_text=row_dict['command'],
> print_text=colored_cmd)
> print(f'{padded_cmd} # rtime@
> {Term.YELLOW}{cmd_time}{Term.ENDC}')
> """
> >But I found that it did not perform the correct conversion according to the time zone setting on the machine, as shown below:
> >```shell
> >werner@X10DAi-00:~$ rm 222222222222222222
> >rm: cannot remove '222222222222222222': No such file or directory
> >werner@X10DAi-00:~$ recent -fo -w . 2222222222222
> >rm 222222222222222222 # rtime@ 2021-08-29 10:57:13
> >werner@X10DAi-00:~$ date
> >Sun 29 Aug 2021 06:57:22 PM CST
> >```
> Might have helped to mention you were in China... To me, CST is North
> America Central Standard Time (and I'd have expected this time of year to
> see CDT - Central Daylight Time)... That led me on a weird meaningless side
> track...
>
> What documentation do you have that says it will display the date/time
> in local timezone? (The README appears to be incorrect -- the utility logs
> unix epoch [UTC seconds since 1970] AS ISO UTC string).
>
> sqlite> select datetime(1092941466, 'unixepoch');
> 2004-08-19 18:51:06
> sqlite> select datetime(1092941466, 'unixepoch', 'localtime');
> 2004-08-19 14:51:06
> sqlite>
> sqlite> select datetime('now', 'localtime');
> 2021-08-30 18:50:19
> sqlite> select datetime('now');
> 2021-08-30 22:50:32
> sqlite>
>
> I'm in EDT (Eastern Daylight Time) -- so 4 hours behind UTC.
>
>
> --
> Wulfraed Dennis Lee Bieber AF6VN
> wlf...@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
--
https://mail.python.org/mailman/listinfo/python-list

On 2021-08-31 02:16, dn via Python-list wrote:
> On 31/08/2021 11.07, Dennis Lee Bieber wrote:
>> On Sun, 29 Aug 2021 19:49:19 -0700 (PDT), "hongy...@gmail.com"
>> <hongyi.zhao@gmail.com> declaimed the following:
> ...
>
>> Might have helped to mention you were in China... To me, CST is North
>> America Central Standard Time (and I'd have expected this time of year to
>> see CDT - Central Daylight Time)... That led me on a weird meaningless side
>> track...
> ...
>
>> I'm in EDT (Eastern Daylight Time) -- so 4 hours behind UTC.
>
>
> Which is correct?
>
> CST in China
> https://www.timeanddate.com/time/zones/cst-china
>
> CST in North America
> https://www.timeanddate.com/time/zones/cst
>
> and not to mention Cuba
> https://www.timeanddate.com/time/zones/
>
[snip]
What annoys me is when someone starts that a webinar will start at, say,
xx ET. I have to know which country that person is in and whether
daylight savings is currently in effect (EST or EDT?) so that I can
convert to my local time.

It's so much easier to use UTC.

I know what timezone I'm in and whether daylight savings is currently in
effect here, so I know the local offset from UTC.
--
https://mail.python.org/mailman/listinfo/python-list

On Tue, Aug 31, 2021 at 8:55 PM MRAB <python@mrabarnett.plus.com> wrote:
>
> On 2021-08-31 02:16, dn via Python-list wrote:
> > On 31/08/2021 11.07, Dennis Lee Bieber wrote:
> >> On Sun, 29 Aug 2021 19:49:19 -0700 (PDT), "hongy...@gmail.com"
> >> <hongyi.zhao@gmail.com> declaimed the following:
> > ...
> >
> >> Might have helped to mention you were in China... To me, CST is North
> >> America Central Standard Time (and I'd have expected this time of year to
> >> see CDT - Central Daylight Time)... That led me on a weird meaningless side
> >> track...
> > ...
> >
> >> I'm in EDT (Eastern Daylight Time) -- so 4 hours behind UTC.
> >
> >
> > Which is correct?
> >
> > CST in China
> > https://www.timeanddate.com/time/zones/cst-china
> >
> > CST in North America
> > https://www.timeanddate.com/time/zones/cst
> >
> > and not to mention Cuba
> > https://www.timeanddate.com/time/zones/
> >
> [snip]
> What annoys me is when someone starts that a webinar will start at, say,
> xx ET. I have to know which country that person is in and whether
> daylight savings is currently in effect (EST or EDT?) so that I can
> convert to my local time.

If someone says "ET", then I would assume they mean America/New_York -
it seems that only in the US do people so utterly assume that everyone
else is in the same country. In Europe, I hear people say "CEST" and
such (though I still prefer "Europe/Prague" or whatever country
they're in), so the only issue there is that they don't always say
"CEDT" when it's daylight time.

> It's so much easier to use UTC.
>
> I know what timezone I'm in and whether daylight savings is currently in
> effect here, so I know the local offset from UTC.

Yeah. I do recommend making good use of the IANA tzinfo database
though (especially since Python 3.9 made that a bit easier to access),
as it's usually easier to get people to tell you what city/state
they're in, rather than whether daylight time will be active or not.
(It might take a little bit of translation to figure out that, for
instance, New Brunswick CA is America/Halifax, but that's not too hard
usually.) Letting tzinfo do all the work means you don't have to fret
about anyone's daylight saving transition dates, or whether they've
decided to change their clocks by half an hour to be different from
Japan's clocks, or to have DST not applicable during Ramadan, or to
have double DST, or double-negative DST. And yes, those are all real,
because you can't make up anything as insane as actual clock politics.

(I find the Ireland situation particularly amusing. Northern Ireland,
being part of the UK, operates on London time, with clocks advancing
one hour for summer. The Republic of Ireland, on the other hand, has a
standard time which is one hour later than Greenwich's, but then they
subtract an hour during winter, returning to standard time in summer.
So when the rest of Europe adds an hour, Ireland stops subtracting
one. Clocks in Belfast and Dublin always show the same times.)

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

On 31/08/2021 13:45, Chris Angelico wrote:

> (I find the Ireland situation particularly amusing.

Time zones and daylight saving arrangements in particular are a
nightmare at the micro level. I once worked on a large customer
support application which required all dates/times to be viewable
in UTC plus any of:
- The local support centre's time (eg. Tokyo, Japan)
- The customer organization's local time(eg. Seoul, Korea)
- The local site time (some remote island in the pacific...)

The big problem was the last one since some small countries
have local arrangements for timezones that don't conform to
the official ones. One pacific island had dual "patrons" and to
avoid offending either they adopted a non-standard "timezone"
half-way between the two patron's zones!

In another case we had the principality of Andorra deciding
to put off switching to DST for an extra week because it
would make the snow melt faster and spoil the skiing!
This was decided by the council on the Friday before it
was due to happen and announced on the local radio...

I got more grey hairs on that project than any other.

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


--
https://mail.python.org/mailman/listinfo/python-list

On 01/09/2021 00.45, Chris Angelico wrote:
> On Tue, Aug 31, 2021 at 8:55 PM MRAB <python@mrabarnett.plus.com> wrote:
>> On 2021-08-31 02:16, dn via Python-list wrote:
>>> On 31/08/2021 11.07, Dennis Lee Bieber wrote:
>>>> On Sun, 29 Aug 2021 19:49:19 -0700 (PDT), "hongy...@gmail.com"
>>>> <hongyi.zhao@gmail.com> declaimed the following:
>>> ...
>>>
>>>> Might have helped to mention you were in China... To me, CST is North
>>>> America Central Standard Time (and I'd have expected this time of year to
>>>> see CDT - Central Daylight Time)... That led me on a weird meaningless side
>>>> track...
>>> ...
>>>
>>>> I'm in EDT (Eastern Daylight Time) -- so 4 hours behind UTC.
>>>
>>>
>> What annoys me is when someone starts that a webinar will start at, say,
>> xx ET. I have to know which country that person is in and whether
>> daylight savings is currently in effect (EST or EDT?) so that I can
>> convert to my local time.
>
> If someone says "ET", then I would assume they mean America/New_York -
> it seems that only in the US do people so utterly assume that everyone
> else is in the same country. In Europe, I hear people say "CEST" and
> such (though I still prefer "Europe/Prague" or whatever country
> they're in), so the only issue there is that they don't always say
> "CEDT" when it's daylight time.

We tackle the inter-related subjects of "localisation" and
"internationalisation" in our (non-Python) training courses.

The 'problem' with a local-time, eg "0900 ET" (as above), is that it is
local. It is really only intended to communicate locally.

The definitions of "local" and 'local understanding' do vary. For
example, Australia stretches over multiple time-zones and thus people in
Melbourne are familiar with the idea of adjusting a Sydney-time to their
local clock. Similarly, US-based folk. However, many other localities
don't have such concerns and thus don't think that way!


At the level of "inter-personal communication", should one say (only)
what is in your head, or perform the 'translation' as a politeness to
your reader?

In @Chris' example, 'the reader' could be anywhere in the world. So, it
would be difficult, and lengthy, to provide for all - but should you
write such an invitation 'for all' ("Hi Everyone"), or should it be
addressed to the individual reader ("Dear Colleague")?

After years (decades!) of being woken in the early-hours of the morning
by (time-zone-ignorant) colleagues, my recommendation is to use both!


If the invitation is mine, typically I will write ("transmit") my local
time, because that is how I'm thinking as I type. On a
second-pass/editing the text, I will be considering how the reader will
"receive" the information.

If we're talking about a staff-meeting, it may be possible to list the
reader's time/date. In the case of an webinar hoping to attract
international participation, the recommendation is to add a
UTC-equivalent. (ideas developed, below)



>> It's so much easier to use UTC.
>>
>> I know what timezone I'm in and whether daylight savings is currently in
>> effect here, so I know the local offset from UTC.

Exactly! The very purpose of having an "international" standard.

Also, the very reason why Python has two groups of time-and-date
functions - so that one may work in local-time, or international-time/UTC.


Please note, the adjustments described (offsets) are *numeric*.
Accordingly, being told that one of our members resides 'at' UTC-4, and
knowing that I am currently at UTC+12, we can figure-out a 16-hour
'time-difference'.

NB in reality, having too few fingers, I would go 'the other way' (ie 24
- 16 ) and work with the idea that our colleague's clock is eight-hours
'ahead' of mine (so, as I've recently 'passed' 0800, that would make it
~1600/4pm for him - remembering that I am already 'in' Wednesday,
whereas Americans are still struggling to catch-up by finishing Tuesday)


> Yeah. I do recommend making good use of the IANA tzinfo database
> though (especially since Python 3.9 made that a bit easier to access),
> as it's usually easier to get people to tell you what city/state
> they're in, rather than whether daylight time will be active or not.
> (It might take a little bit of translation to figure out that, for
> instance, New Brunswick CA is America/Halifax, but that's not too hard
> usually.) Letting tzinfo do all the work means you don't have to fret
> about anyone's daylight saving transition dates, or whether they've
> decided to change their clocks by half an hour to be different from
> Japan's clocks, or to have DST not applicable during Ramadan, or to
> have double DST, or double-negative DST. And yes, those are all real,
> because you can't make up anything as insane as actual clock politics.

So, given that it is a NUMERIC calculation, dispense with "New Brunswick
CA is America/Halifax"; and avoid "Atlantic Time", "Atlantic Standard
Time", "Atlantic Daylight Time", "AT", "ADT", or "AST", and express the
time numerically: "17:00-3"

Given that, someone at UTC-4 knows that his/her rendez-vous will be
"1600", and I can figure it to be "0800" for me:

1700 - -3 = 20:00 (to calculate UTC), then UTC-4 = 16:00
and
1700 - -3 = 20:00 (to calculate UTC), then UTC+12 = 32:00,
rounding to 24hrs: 08:00
(the next day)


For many of us, the mental-calculations are relatively easy to manage.
For Python the code is trivial. Computation is easier than terminology
'translation' (particularly when one has to research the terms first!
- did you know what "ADT" meant?)


You may have noticed that competent web-sites for courses, conferences,
and the like, will offer 'widgets' that perform these calculations for
the reader (based upon the time-zone reported by your client
web-browser). This is very handy - and may I suggest, should be
requirement for international operations - after all, don't we call it
"the WORLD-WIDE web"?


> (I find the Ireland situation particularly amusing. Northern Ireland,
> being part of the UK, operates on London time, with clocks advancing
> one hour for summer. The Republic of Ireland, on the other hand, has a
> standard time which is one hour later than Greenwich's, but then they
> subtract an hour during winter, returning to standard time in summer.
> So when the rest of Europe adds an hour, Ireland stops subtracting
> one. Clocks in Belfast and Dublin always show the same times.)

Per @Alan's response, I have had 'hairy experiences' with time-zones and
people 'doing their own thing'. It's all good-fun until someone misses a
meeting and the boss...


Teasing @Chris: I'm not sure why it should be amusing that two entities
called 'Ireland' should have different time-zones (pot?kettle) - after
all, does "Western Australia" use the same time-zone as "South
Australia"? For that matter, the same as the bulk of the Australian
population?


The time-zone which perplexes me most, is India. This because it is not
only a different hour, but also requires a 30-minute off-set - operating
at UTC+5:30!

Fortunately, like China, the entire country (officially) operates in the
same time-zone. Accordingly, there is less consideration about
working-out what time it is in Pune cf Kolkata, than between (say) San
Francisco and Denver - although they are in the same country, are they
in the same time-zone, or not?
(they aren't!)

--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list

On Wed, Sep 1, 2021 at 6:38 AM dn via Python-list
<python-list@python.org> wrote:
> > Yeah. I do recommend making good use of the IANA tzinfo database
> > though (especially since Python 3.9 made that a bit easier to access),
> > as it's usually easier to get people to tell you what city/state
> > they're in, rather than whether daylight time will be active or not.
> > (It might take a little bit of translation to figure out that, for
> > instance, New Brunswick CA is America/Halifax, but that's not too hard
> > usually.) Letting tzinfo do all the work means you don't have to fret
> > about anyone's daylight saving transition dates, or whether they've
> > decided to change their clocks by half an hour to be different from
> > Japan's clocks, or to have DST not applicable during Ramadan, or to
> > have double DST, or double-negative DST. And yes, those are all real,
> > because you can't make up anything as insane as actual clock politics.
>
> So, given that it is a NUMERIC calculation, dispense with "New Brunswick
> CA is America/Halifax"; and avoid "Atlantic Time", "Atlantic Standard
> Time", "Atlantic Daylight Time", "AT", "ADT", or "AST", and express the
> time numerically: "17:00-3"
>
> Given that, someone at UTC-4 knows that his/her rendez-vous will be
> "1600", and I can figure it to be "0800" for me:
>
> 1700 - -3 = 20:00 (to calculate UTC), then UTC-4 = 16:00
> and
> 1700 - -3 = 20:00 (to calculate UTC), then UTC+12 = 32:00,
> rounding to 24hrs: 08:00
> (the next day)

No, that's not reliable... because of that abomination called Daylight
Saving Time. Since I used New Brunswick, and since she's just gone
online, I'll use a specific example:

DeviCat livestreams at 6pm every Tuesday (and other times, but I'm
going to focus on a weekly event here). Since she lives in NB, Canada,
she defines that time by what IANA refers to as America/Halifax.

I want to be there at the start of each stream, since I'm one of her
moderators. But I live in a suburb of Melbourne - my clock shows what
IANA calls Australia/Melbourne.

To turn this into a purely mathematical calculation, you have to know
exactly when she will go on or off DST, and when I will go on or off.
Trying to turn it into an offset is going to fail badly as soon as you
talk about "next Tuesday" and one of us is shifting DST this weekend.

That's why it's better to let Python (or something) handle the whole
thing. Don't concern yourself with exactly what the hour differences
are, or which way DST is going, or anything; just convert Halifax time
to Melbourne time.

> For many of us, the mental-calculations are relatively easy to manage.
> For Python the code is trivial. Computation is easier than terminology
> 'translation' (particularly when one has to research the terms first!
> - did you know what "ADT" meant?)

I asked DeviCat what country and province ("state" in other regions)
she lived in, and then confirmed with her that Halifax time was what
her clock showed. The term "ADT" was never relevant.

In a lot of situations, you don't even need to ask the human - you can
let the web browser or desktop app report the timezone. The app can
say something like "In order to schedule this event, <X> will need to
know your time zone. Is that okay?" and then send the IANA timezone
name.

> Teasing @Chris: I'm not sure why it should be amusing that two entities
> called 'Ireland' should have different time-zones (pot?kettle) - after
> all, does "Western Australia" use the same time-zone as "South
> Australia"? For that matter, the same as the bulk of the Australian
> population?

Western Australia uses Australia/Perth timezone, and South Australia
uses Australia/Adelaide. They're different base times from the east
coast where I am by two hours, and half an hour, respectively; and
they have different DST rules.

On the east coast, we all have the same winter time, but in summer,
Melbourne, Sydney, and Hobart move clocks forward, but Brisbane
doesn't.

> The time-zone which perplexes me most, is India. This because it is not
> only a different hour, but also requires a 30-minute off-set - operating
> at UTC+5:30!

Yup, we got that too... Adelaide is half an hour back from Melbourne
(UTC+9:30). But it gets worse. Kathmandu is on a quarter hour. And the
Chatham Islands (part of New Zealand) are 12:45 ahead of UTC in
winter, and then they add an hour of DST in summer, putting them at
UTC+13:45.

> Fortunately, like China, the entire country (officially) operates in the
> same time-zone. Accordingly, there is less consideration about
> working-out what time it is in Pune cf Kolkata, than between (say) San
> Francisco and Denver - although they are in the same country, are they
> in the same time-zone, or not?
> (they aren't!)

That would be convenient for working within China, but on the flip
side, it means that geographically-nearby locations can have vastly
different clocks. Oh, and one of those nearby locations is Nepal. So
it's possible to step across a border and have your clock change from
3AM to 5:15AM. Yeah that's gotta be fun!

But ultimately, it all just means that timezones are too hard for
humans to handle, and we MUST handle them using IANA's database. It is
the only way.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

On 2021-09-01 at 08:36:55 +1200,
dn via Python-list <python-list@python.org> wrote:

> ... there is less consideration about working-out what time it is in
> Pune cf Kolkata, than between (say) San Francisco and Denver -
> although they are in the same country, are they in the same time-zone,
> or not? (they aren't!)

What about Phoenix? In the winter, it's the same time there as it is in
San Francisco, but in the summer, it's the same time there as it is in
Denver (Phoenix doesn't observe Daylight Saving Time).

And then there's Indiana, a medium size state that tends to get ignored
(they used to advertise "there's more than just corn in Indiana"). Most
of Indiana is in US/Eastern, but the cities that are (for practical
purposes) suburbs of Chicago are in US/Central (aka America/Chicago).

ChrisA is right; you can't make this [stuff] up.

Having lived in the United States my entire life (and being a nerd), I
can confirm that (1) I'm used to it and handle it as well as possible,
but (2) many people are not and don't.
--
https://mail.python.org/mailman/listinfo/python-list

On Wed, Sep 1, 2021 at 7:17 AM <2QdxY4RzWzUUiLuE@potatochowder.com> wrote:
>
> On 2021-09-01 at 08:36:55 +1200,
> dn via Python-list <python-list@python.org> wrote:
>
> > ... there is less consideration about working-out what time it is in
> > Pune cf Kolkata, than between (say) San Francisco and Denver -
> > although they are in the same country, are they in the same time-zone,
> > or not? (they aren't!)
>
> What about Phoenix? In the winter, it's the same time there as it is in
> San Francisco, but in the summer, it's the same time there as it is in
> Denver (Phoenix doesn't observe Daylight Saving Time).

I prefer to say: In winter, San Francisco (or Los Angeles) is the same
as Phoenix, but in summer, Los Angeles changes its clocks away, and
Denver changes to happen to be the same as Phoenix.

> And then there's Indiana, a medium size state that tends to get ignored
> (they used to advertise "there's more than just corn in Indiana"). Most
> of Indiana is in US/Eastern, but the cities that are (for practical
> purposes) suburbs of Chicago are in US/Central (aka America/Chicago).

At least the US has governed DST transitions. As I understand it, any
given city has to follow one of the standard time zones, and may
EITHER have no summer time, OR transition at precisely 2AM/3AM local
time on the federally-specified dates. (I think the EU has also
mandated something similar for member states.)

If we could abolish DST world-wide, life would be far easier. All the
rest of it would be easy enough to handle.

> ChrisA is right; you can't make this [stuff] up.

Yeah. And if you think you've heard it all, sign up for the
tzdata-announce mailing list and wait for the next phenomenon. I think
Egypt (Africa/Cairo) is currently in the lead for weirdest timezone
change, for (with short notice) announcing that they'd have DST during
summer but not during Ramadan. Since "summer" is defined by a solar
calendar and "Ramadan" is defined by a lunar calendar, that means the
DST exclusion might happen entirely in winter (no effect), at one end
or other of summer (shortens DST, just changes the dates), or in the
middle of summer (DST on, DST off, DST on, DST off, in a single year).
But they will, at some point, be eclipsed by an even more bizarre
timezone change. I don't dare try to predict what will happen, because
I know that the reality will be even worse....

> Having lived in the United States my entire life (and being a nerd), I
> can confirm that (1) I'm used to it and handle it as well as possible,
> but (2) many people are not and don't.

Yup, absolutely. I've been working internationally for a number of
years now, so my employment has been defined by a clock that isn't my
own. I got used to it and developed tools and habits, but far too many
people don't, and assume that simple "add X hours" conversions
suffice.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

On 31/08/2021 16.13, Chris Angelico wrote:

>
> But ultimately, it all just means that timezones are too hard for
> humans to handle, and we MUST handle them using IANA's database. It is
> the only way.

Tom Scott makes this point quite strongly on Computerphile:

<https://www.youtube.com/watch?v=-5wpm-gesOY>

And amusingly.

--
Michael F. Stemper
Always remember that you are unique. Just like everyone else.
--
https://mail.python.org/mailman/listinfo/python-list

On 2021-09-01 at 07:32:43 +1000,
Chris Angelico <rosuav@gmail.com> wrote:

> On Wed, Sep 1, 2021 at 7:17 AM <2QdxY4RzWzUUiLuE@potatochowder.com> wrote:

> > What about Phoenix? In the winter, it's the same time there as it is in
> > San Francisco, but in the summer, it's the same time there as it is in
> > Denver (Phoenix doesn't observe Daylight Saving Time).
>
> I prefer to say: In winter, San Francisco (or Los Angeles) is the same
> as Phoenix, but in summer, Los Angeles changes its clocks away, and
> Denver changes to happen to be the same as Phoenix.

Not exactly. Sort of. Phoenix and Denver are both in America/Denver
(aka US/Mountain), but only Denver observes DST. San Francisco and Los
Angeles are both in America/Los_Angeles, and both observe DST.

> At least the US has governed DST transitions. As I understand it, any
> given city has to follow one of the standard time zones, and may
> EITHER have no summer time, OR transition at precisely 2AM/3AM local
> time on the federally-specified dates. (I think the EU has also
> mandated something similar for member states.)

That's my understanding, too.

> If we could abolish DST world-wide, life would be far easier. All the
> rest of it would be easy enough to handle.

Agreed.

> ... I think Egypt (Africa/Cairo) is currently in the lead for weirdest
> timezone change ...

Yeah, I read about that somewhere. Remember when the Pope declared that
September should skip a bunch of days?

> > Having lived in the United States my entire life (and being a nerd), I
> > can confirm that (1) I'm used to it and handle it as well as possible,
> > but (2) many people are not and don't.
>
> Yup, absolutely. I've been working internationally for a number of
> years now, so my employment has been defined by a clock that isn't my
> own. I got used to it and developed tools and habits, but far too many
> people don't, and assume that simple "add X hours" conversions
> suffice.

Way back in the 1990s, I was working with teams in Metro Chicago, Tel
Aviv, and Tokyo (three separate teams, three really separate time zones,
at least two seaprate DST transition dates). I changed my wristwatch to
24 hour time (and never looked back). I tried UTC for a while, which
was cute, but confusing.
--
https://mail.python.org/mailman/listinfo/python-list

On Wed, Sep 1, 2021 at 7:54 AM <2QdxY4RzWzUUiLuE@potatochowder.com> wrote:
>
> On 2021-09-01 at 07:32:43 +1000,
> Chris Angelico <rosuav@gmail.com> wrote:
>
> > On Wed, Sep 1, 2021 at 7:17 AM <2QdxY4RzWzUUiLuE@potatochowder.com> wrote:
>
> > > What about Phoenix? In the winter, it's the same time there as it is in
> > > San Francisco, but in the summer, it's the same time there as it is in
> > > Denver (Phoenix doesn't observe Daylight Saving Time).
> >
> > I prefer to say: In winter, San Francisco (or Los Angeles) is the same
> > as Phoenix, but in summer, Los Angeles changes its clocks away, and
> > Denver changes to happen to be the same as Phoenix.
>
> Not exactly. Sort of. Phoenix and Denver are both in America/Denver
> (aka US/Mountain), but only Denver observes DST. San Francisco and Los
> Angeles are both in America/Los_Angeles, and both observe DST.

America/Phoenix is a separate time zone from America/Denver. During
winter they represent the same time, but during summer, Phoenix
doesn't change its offset, and Denver does.

(San Francisco isn't an IANA timezone; the city precisely follows Los
Angeles time.)

> > ... I think Egypt (Africa/Cairo) is currently in the lead for weirdest
> > timezone change ...
>
> Yeah, I read about that somewhere. Remember when the Pope declared that
> September should skip a bunch of days?

Well, that's from transitioning from the Julian calendar to the
Gregorian. The same transition was done in different countries at
different times. The Pope made the declaration for the Catholic church
in 1582, and all countries whose official religion was Catholic
changed at the same time; other countries chose their own schedules
for the transition. Notably, Russia converted in 1918, immediately
after the "October Revolution", which happened on the 25th of October
on the Julian calendar, but the 7th of November on the Gregorian.

> Way back in the 1990s, I was working with teams in Metro Chicago, Tel
> Aviv, and Tokyo (three separate teams, three really separate time zones,
> at least two seaprate DST transition dates). I changed my wristwatch to
> 24 hour time (and never looked back). I tried UTC for a while, which
> was cute, but confusing.

I tried UTC for a while too, but it became easier to revert to local
time for my watch and just do the conversions directly.

Perhaps, in the future, we will all standardize on UTC, and daylight
time will be a historical relic. And then, perhaps, we will start
getting frustrated at relativity-based time discrepancies ("it's such
a pain scheduling anything with someone on Mars, their clocks move
faster than ours do!").

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

On 2021-08-31 22:53, 2QdxY4RzWzUUiLuE@potatochowder.com wrote:
> On 2021-09-01 at 07:32:43 +1000,
> Chris Angelico <rosuav@gmail.com> wrote:
>
>> On Wed, Sep 1, 2021 at 7:17 AM <2QdxY4RzWzUUiLuE@potatochowder.com> wrote:
>
>> > What about Phoenix? In the winter, it's the same time there as it is in
>> > San Francisco, but in the summer, it's the same time there as it is in
>> > Denver (Phoenix doesn't observe Daylight Saving Time).
>>
>> I prefer to say: In winter, San Francisco (or Los Angeles) is the same
>> as Phoenix, but in summer, Los Angeles changes its clocks away, and
>> Denver changes to happen to be the same as Phoenix.
>
> Not exactly. Sort of. Phoenix and Denver are both in America/Denver
> (aka US/Mountain), but only Denver observes DST. San Francisco and Los
> Angeles are both in America/Los_Angeles, and both observe DST.
>
>> At least the US has governed DST transitions. As I understand it, any
>> given city has to follow one of the standard time zones, and may
>> EITHER have no summer time, OR transition at precisely 2AM/3AM local
>> time on the federally-specified dates. (I think the EU has also
>> mandated something similar for member states.)
>
> That's my understanding, too.
>
[snip]
In the EU, DST in the member states changes at the same time. It's not
like the US where it ripples across the timezones, so the differences
vary during the change. It all happens in one go.
--
https://mail.python.org/mailman/listinfo/python-list

On Wed, Sep 1, 2021 at 8:22 AM MRAB <python@mrabarnett.plus.com> wrote:
>
> [snip]
> In the EU, DST in the member states changes at the same time. It's not
> like the US where it ripples across the timezones, so the differences
> vary during the change. It all happens in one go.
>

Ah, good to know. I think that actually makes a lot of sense; in the
US, they try to let everyone pretend that the rest of the world
doesn't exist ("we always change at 2AM"), but in Europe, they try to
synchronize for the convenience of commerce ("everyone changes at 1AM
UTC").

A quick browse of Wikipedia suggests that some European countries
(outside of the EU, which mandates DST transitions) have constant
year-round UTC offsets. In theory, there could be a non-EU country
that observes DST with different dates, but I can't find any examples.
Here's hoping, hehe.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

On 01/09/2021 09.13, Chris Angelico wrote:
> On Wed, Sep 1, 2021 at 6:38 AM dn via Python-list
> <python-list@python.org> wrote:
>>> Yeah. I do recommend making good use of the IANA tzinfo database
>>> though (especially since Python 3.9 made that a bit easier to access),
>>> as it's usually easier to get people to tell you what city/state
>>> they're in, rather than whether daylight time will be active or not.
>>> (It might take a little bit of translation to figure out that, for
>>> instance, New Brunswick CA is America/Halifax, but that's not too hard
>>> usually.) Letting tzinfo do all the work means you don't have to fret
>>> about anyone's daylight saving transition dates, or whether they've
>>> decided to change their clocks by half an hour to be different from
>>> Japan's clocks, or to have DST not applicable during Ramadan, or to
>>> have double DST, or double-negative DST. And yes, those are all real,
>>> because you can't make up anything as insane as actual clock politics.
>>
>> So, given that it is a NUMERIC calculation, dispense with "New Brunswick
>> CA is America/Halifax"; and avoid "Atlantic Time", "Atlantic Standard
>> Time", "Atlantic Daylight Time", "AT", "ADT", or "AST", and express the
>> time numerically: "17:00-3"
>>
>> Given that, someone at UTC-4 knows that his/her rendez-vous will be
>> "1600", and I can figure it to be "0800" for me:
>>
>> 1700 - -3 = 20:00 (to calculate UTC), then UTC-4 = 16:00
>> and
>> 1700 - -3 = 20:00 (to calculate UTC), then UTC+12 = 32:00,
>> rounding to 24hrs: 08:00
>> (the next day)
>
> No, that's not reliable... because of that abomination called Daylight
> Saving Time. Since I used New Brunswick, and since she's just gone
> online, I'll use a specific example:
>
> DeviCat livestreams at 6pm every Tuesday (and other times, but I'm
> going to focus on a weekly event here). Since she lives in NB, Canada,
> she defines that time by what IANA refers to as America/Halifax.
>
> I want to be there at the start of each stream, since I'm one of her
> moderators. But I live in a suburb of Melbourne - my clock shows what
> IANA calls Australia/Melbourne.
>
> To turn this into a purely mathematical calculation, you have to know
> exactly when she will go on or off DST, and when I will go on or off.
> Trying to turn it into an offset is going to fail badly as soon as you
> talk about "next Tuesday" and one of us is shifting DST this weekend.
>
> That's why it's better to let Python (or something) handle the whole
> thing. Don't concern yourself with exactly what the hour differences
> are, or which way DST is going, or anything; just convert Halifax time
> to Melbourne time.

OK, I admit it: I am so lazy that I don't use my fingers (nor my toes!)
but expect my poor, over-worked (and under-paid) computer to calculate
it all for me...


I should have split the earlier explanation of two calculations, more
clearly:

Devicat can declare the start as "6pm" ("localisation")
and state that the time-zone is UTC-3
- or as @MRAB suggested, translate it to "21:00 UTC"
("internationalisation")

You (@Chris) then perform the second-half calculation, by adjusting the
UTC-value to your time-zone.

- and were I to attend, would personalise ("localise") the time
similarly - but using my locality's (different) UTC-offset.


I agree, the idea of 'Summer Time' is a thorough pain - even more-so
when the host publishes in local-time but forgets that there will be a
"spring forward" or "fall back" between the time of publication and the
meeting-date!

[.the song says "Summer Time, and the living is easy". Unfortunately,
Ella Fitzgerald isn't here to wrap her head around the problem, so I
guess it's up to us...]

Once again, it is a localisation/internationalisation problem. Why would
you/I know, if and when, New Brunswick moves in/out of Summer Time? As
described, it is another 'big ball of mud'.

Far better to have the local deal with 'local issues', and for us to
handle our own (time-zone) problems!
(why should Devicat concern herself with MLB-based issues, or NZST, or
wherever and etc?)

[BTW: welcome to the first day of 'summer'!]


Accordingly, when the Néo-Brunswickoise publishes "6pm", all the locals
will be happy.

If she adds UTC, or the locally-applicable UTC-offset (for Summer-Time,
or not), the international community can make their own and personal
arrangements, without winding-through the opaque and arcane
seasonal-adjustments described!

Plus the virtue(?) of using International Standards!


>> For many of us, the mental-calculations are relatively easy to manage.
>> For Python the code is trivial. Computation is easier than terminology
>> 'translation' (particularly when one has to research the terms first!
>> - did you know what "ADT" meant?)
>
> I asked DeviCat what country and province ("state" in other regions)
> she lived in, and then confirmed with her that Halifax time was what
> her clock showed. The term "ADT" was never relevant.

Ah, but we are back to the original complaint about "CST" or "China Time".

The "New Brunswick" in Canada is quite close to the "New Brunswick" in
New Jersey (USA) - in physical distance, but the two are in distinct
time-zones. (Yes, you did say "CA", but easily 'missed' - by author and
reader alike)

Confusing the two New Brunswick-s would make you late-to-the-party!


> In a lot of situations, you don't even need to ask the human - you can
> let the web browser or desktop app report the timezone. The app can
> say something like "In order to schedule this event, <X> will need to
> know your time zone. Is that okay?" and then send the IANA timezone
> name.

Those are the better publishers.

Too many do not - have yet to figure-out the implications of the words
behind "www". Sigh!

(have been glad to hear others grumping about the expression of times -
it's not just me then!)


>> Teasing @Chris: I'm not sure why it should be amusing that two entities
>> called 'Ireland' should have different time-zones (pot?kettle) - after
>> all, does "Western Australia" use the same time-zone as "South
>> Australia"? For that matter, the same as the bulk of the Australian
>> population?
>
> Western Australia uses Australia/Perth timezone, and South Australia
> uses Australia/Adelaide. They're different base times from the east
> coast where I am by two hours, and half an hour, respectively; and
> they have different DST rules.
>
> On the east coast, we all have the same winter time, but in summer,
> Melbourne, Sydney, and Hobart move clocks forward, but Brisbane
> doesn't.

Did I say that "Summer Time" is a pain?

When (ordinary) folk try to explain it to me, they talk about 'the
farmers' and agriculture. Every dairy farmer I've spoken with says it's
all too-stupid - instead of milking at 0500, they start at 4am - no cow
wears a watch!

All this extra daylight is not good anyway - it fades the curtains more
quickly!

Living in the tropics I can't say I ever missed the sleep-disturbances
caused by Summer time!


>> The time-zone which perplexes me most, is India. This because it is not
>> only a different hour, but also requires a 30-minute off-set - operating
>> at UTC+5:30!
>
> Yup, we got that too... Adelaide is half an hour back from Melbourne
> (UTC+9:30). But it gets worse. Kathmandu is on a quarter hour. And the
> Chatham Islands (part of New Zealand) are 12:45 ahead of UTC in
> winter, and then they add an hour of DST in summer, putting them at
> UTC+13:45.

...the pain keeps getting worse...


>> Fortunately, like China, the entire country (officially) operates in the
>> same time-zone. Accordingly, there is less consideration about
>> working-out what time it is in Pune cf Kolkata, than between (say) San
>> Francisco and Denver - although they are in the same country, are they
>> in the same time-zone, or not?
>> (they aren't!)
>
> That would be convenient for working within China, but on the flip
> side, it means that geographically-nearby locations can have vastly
> different clocks. Oh, and one of those nearby locations is Nepal. So
> it's possible to step across a border and have your clock change from
> 3AM to 5:15AM. Yeah that's gotta be fun!

Been there. Done that. It is!
(not that specific border-crossing)

"Jet lag" is one thing. Switching hemispheres I find dislocating. Having
one's 'clock' switched by amounts other than round-hour amounts is just
plain cruel!


> But ultimately, it all just means that timezones are too hard for
> humans to handle, and we MUST handle them using IANA's database. It is
> the only way.

I had (still have) a 'digi-ana' watch. It shows local time using the
(analog) hands, and keeps 'home time' as a (smaller) digital display.

Similarly, a travel alarm clock with a rotational-switch on the front,
allowing the time (and/or the alarm time) to be set and displayed using
any time-zone (not counting the half- and quarter-hour off-sets. Grrr!)


PS I think my (Linux) computer is basically set to UTC. The desktop
performs localisation. Then I added a 'widget' which extends the usual
clock to give World Times. Failing that, there are numerous web-sites
which offer time-translations or clocks showing times at chosen locales.


The Internet 'standard' which "defines a date and time format for use in
Internet protocols" is RFC3339:
https://datatracker.ietf.org/doc/html/rfc3339
It describes itself as "a profile of the ISO 8601 standard"

ISO do not publish their standards on the web (nor for $free)
Wikipedia has good coverage of ISO 8601, starting at
https://en.wikipedia.org/wiki/ISO_8601

Python's (and *nix - but not MS-Win) times are managed through the
"tzdb". This was recently updated/upgraded with "PEP 615 -- Support for
the IANA Time Zone Database in the Standard Library":
https://www.python.org/dev/peps/pep-0615/ (implemented in Python 3.9)

(there are other (accepted and implemented) PEPs dealing with 'time', eg
improving accuracy to parts of a second, dealing with the "fold"
('losing' or 'duplicating' times/timestamps caused by Daylight Saving
clock shifts), etc.)

The tzdb is maintained by IANA (the Internet Assigned Numbers
Authority): https://www.iana.org/time-zones; which is where we find such
terms as "America/Halifax". It aims to handle the pain of "time zone
boundaries, UTC offsets, and daylight-saving rules". However, it is not
a standard!

A couple of our training-courses' web-refs [usual disclaimer]:
https://www.w3.org/International/articles/definitions-time/index.en
https://www.w3.org/International/core/2005/09/timezone.html

If you still want to know more/have managed to keep your head in the
game for all this time, there's an extensive discussion and list of
resources at https://data.iana.org/time-zones/tz-link.html
--
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list

On 2021-08-31 23:31, Chris Angelico wrote:
> On Wed, Sep 1, 2021 at 8:22 AM MRAB <python@mrabarnett.plus.com> wrote:
>>
>> [snip]
>> In the EU, DST in the member states changes at the same time. It's not
>> like the US where it ripples across the timezones, so the differences
>> vary during the change. It all happens in one go.
>>
>
> Ah, good to know. I think that actually makes a lot of sense; in the
> US, they try to let everyone pretend that the rest of the world
> doesn't exist ("we always change at 2AM"), but in Europe, they try to
> synchronize for the convenience of commerce ("everyone changes at 1AM
> UTC").
>
> A quick browse of Wikipedia suggests that some European countries
> (outside of the EU, which mandates DST transitions) have constant
> year-round UTC offsets. In theory, there could be a non-EU country
> that observes DST with different dates, but I can't find any examples.
> Here's hoping, hehe.
>
It goes forwards on the last Sunday of March and back on the last Sunday
of October.
--
https://mail.python.org/mailman/listinfo/python-list

On Wed, Sep 1, 2021 at 9:20 AM dn via Python-list
<python-list@python.org> wrote:
>
> On 01/09/2021 09.13, Chris Angelico wrote:
> > On Wed, Sep 1, 2021 at 6:38 AM dn via Python-list
> > <python-list@python.org> wrote:
> >>> Yeah. I do recommend making good use of the IANA tzinfo database
> >>> though (especially since Python 3.9 made that a bit easier to access),
> >>> as it's usually easier to get people to tell you what city/state
> >>> they're in, rather than whether daylight time will be active or not.
> >>> (It might take a little bit of translation to figure out that, for
> >>> instance, New Brunswick CA is America/Halifax, but that's not too hard
> >>> usually.) Letting tzinfo do all the work means you don't have to fret
> >>> about anyone's daylight saving transition dates, or whether they've
> >>> decided to change their clocks by half an hour to be different from
> >>> Japan's clocks, or to have DST not applicable during Ramadan, or to
> >>> have double DST, or double-negative DST. And yes, those are all real,
> >>> because you can't make up anything as insane as actual clock politics.
> >>
> >> So, given that it is a NUMERIC calculation, dispense with "New Brunswick
> >> CA is America/Halifax"; and avoid "Atlantic Time", "Atlantic Standard
> >> Time", "Atlantic Daylight Time", "AT", "ADT", or "AST", and express the
> >> time numerically: "17:00-3"
> >>
> >> Given that, someone at UTC-4 knows that his/her rendez-vous will be
> >> "1600", and I can figure it to be "0800" for me:
> >>
> >> 1700 - -3 = 20:00 (to calculate UTC), then UTC-4 = 16:00
> >> and
> >> 1700 - -3 = 20:00 (to calculate UTC), then UTC+12 = 32:00,
> >> rounding to 24hrs: 08:00
> >> (the next day)
> >
> > No, that's not reliable... because of that abomination called Daylight
> > Saving Time. Since I used New Brunswick, and since she's just gone
> > online, I'll use a specific example:
> >
> > DeviCat livestreams at 6pm every Tuesday (and other times, but I'm
> > going to focus on a weekly event here). Since she lives in NB, Canada,
> > she defines that time by what IANA refers to as America/Halifax.
> >
> > I want to be there at the start of each stream, since I'm one of her
> > moderators. But I live in a suburb of Melbourne - my clock shows what
> > IANA calls Australia/Melbourne.
> >
> > To turn this into a purely mathematical calculation, you have to know
> > exactly when she will go on or off DST, and when I will go on or off.
> > Trying to turn it into an offset is going to fail badly as soon as you
> > talk about "next Tuesday" and one of us is shifting DST this weekend.
> >
> > That's why it's better to let Python (or something) handle the whole
> > thing. Don't concern yourself with exactly what the hour differences
> > are, or which way DST is going, or anything; just convert Halifax time
> > to Melbourne time.
>
> OK, I admit it: I am so lazy that I don't use my fingers (nor my toes!)
> but expect my poor, over-worked (and under-paid) computer to calculate
> it all for me...
>
>
> I should have split the earlier explanation of two calculations, more
> clearly:
>
> Devicat can declare the start as "6pm" ("localisation")
> and state that the time-zone is UTC-3
> - or as @MRAB suggested, translate it to "21:00 UTC"
> ("internationalisation")
>
> You (@Chris) then perform the second-half calculation, by adjusting the
> UTC-value to your time-zone.
>
> - and were I to attend, would personalise ("localise") the time
> similarly - but using my locality's (different) UTC-offset.

Gotcha gotcha. Unfortunately that, while theoretically easier, is not
correct; she streams at 6pm every week, which means that the UTC time
is *different* in June and December.

> I agree, the idea of 'Summer Time' is a thorough pain - even more-so
> when the host publishes in local-time but forgets that there will be a
> "spring forward" or "fall back" between the time of publication and the
> meeting-date!

Right. Which is basically guaranteed when it's a recurring event.

> Accordingly, when the Néo-Brunswickoise publishes "6pm", all the locals
> will be happy.
>
> If she adds UTC, or the locally-applicable UTC-offset (for Summer-Time,
> or not), the international community can make their own and personal
> arrangements, without winding-through the opaque and arcane
> seasonal-adjustments described!
>
> Plus the virtue(?) of using International Standards!

She'd have to either specify two different UTC times, or two different
local times. Instead, it's safer to just have her publish one local
time (since that's how she's defining things), and let us all convert
directly to our own timezones every time.

> The "New Brunswick" in Canada is quite close to the "New Brunswick" in
> New Jersey (USA) - in physical distance, but the two are in distinct
> time-zones. (Yes, you did say "CA", but easily 'missed' - by author and
> reader alike)

Fair point. I'm not familiar with New Brunswick, New Jersey, USA, but
I know that there are a lot of those kinds of collisions.

> > In a lot of situations, you don't even need to ask the human - you can
> > let the web browser or desktop app report the timezone. The app can
> > say something like "In order to schedule this event, <X> will need to
> > know your time zone. Is that okay?" and then send the IANA timezone
> > name.
>
> Those are the better publishers.
>
> Too many do not - have yet to figure-out the implications of the words
> behind "www". Sigh!
>
> (have been glad to hear others grumping about the expression of times -
> it's not just me then!)

Yup yup. That's why I keep trying to encourage people to post IANA
city names where possible. In a lot of cases, I can just ask someone
"So that's the same as Halifax time?" or "You mean 3pm New York time?"
and it's fine; they don't need to know why I chose some particular
city, but people who live in an area will know what the major nearby
cities are.

> When (ordinary) folk try to explain it to me, they talk about 'the
> farmers' and agriculture. Every dairy farmer I've spoken with says it's
> all too-stupid - instead of milking at 0500, they start at 4am - no cow
> wears a watch!

Yeah, I have no idea where the "farmers" explanation came from.
Growing up, we had some friends in countrified areas, including a
sheep farmer who showed us a ton of stuff about how shearing worked,
how moronic sheep are, and how farming life actually operates. It's
not uncommon for such people to have two clocks: Government Time and
Sun Time. Like you say, no cow wears a watch!

> "Jet lag" is one thing. Switching hemispheres I find dislocating. Having
> one's 'clock' switched by amounts other than round-hour amounts is just
> plain cruel!

I learned to be completely flexible about things, and just slide into
whatever clock the destination has. But it does get very confusing
when you're transiting through some airport and your watch is wrong by
a weird amount...

> PS I think my (Linux) computer is basically set to UTC. The desktop
> performs localisation. Then I added a 'widget' which extends the usual
> clock to give World Times. Failing that, there are numerous web-sites
> which offer time-translations or clocks showing times at chosen locales.

Yes, that's how Linux systems run. I believe Windows always sets the
battery-backed clock in local time though, making dual-booting kinda
finicky.

> Python's (and *nix - but not MS-Win) times are managed through the
> "tzdb". This was recently updated/upgraded with "PEP 615 -- Support for
> the IANA Time Zone Database in the Standard Library":
> https://www.python.org/dev/peps/pep-0615/ (implemented in Python 3.9)

Not sure what you mean by "tzdb" but I presume that's tzdata?
Sometimes called the Olson database?

The change in 3.9 is mainly to make tzdata more generally available,
instead of depending on installing it from PyPI. But whatever your way
of getting it, that's the database to look for.

So many insanities.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

> Yeah. And if you think you've heard it all, sign up for the
> tzdata-announce mailing list and wait for the next phenomenon. I think
> Egypt (Africa/Cairo) is currently in the lead for weirdest timezone
> change, for (with short notice) announcing that they'd have DST during
> summer but not during Ramadan. Since "summer" is defined by a solar
> calendar and "Ramadan" is defined by a lunar calendar, that means the
> DST exclusion might happen entirely in winter (no effect), at one end
> or other of summer (shortens DST, just changes the dates), or in the
> middle of summer (DST on, DST off, DST on, DST off, in a single year).
> But they will, at some point, be eclipsed by an even more bizarre
> timezone change. I don't dare try to predict what will happen, because
> I know that the reality will be even worse....


Similar to the situation where a few US cities maintain a different
time-zone to the rest of the(ir) state, our refinery (in the Middle
East) maintained just such a Ramadan-clock. I think such might be quite
a common practice (which I'll describe, below).

When considered, and motivation aside, it's not so very different from
schemes enabling employees to choose their personal start-time (usually
within a range, eg "glide time"), ideas to reduce 'rush hour' grid-locks
by spreading commuter start/finish times, etc.


At the refinery (computer center), we started one (or was it two) hours
earlier that usual - as close to dawn as possible, ie the beginning of
the daily fast.

"Western employees" could take regular breaks, and usually 'disappeared'
for 'midday meal', somewhere around 1030~1130.

Muslim employees had no breaks. In lieu, they went home early - to be
able to sleep. Later came sunset-prayers, and thereafter
breaking-the-fast. Typically, there would be activities, and more meals,
during the night.

Meantime, the non-Muslims maintained a short 'afternoon shift', going
home commensurately early.

Others in the community were totally confused: "Why didn't you answer
your phone yesterday afternoon?", "a meeting at 0700 - you must be
joking!", etc. The pattern and predictability were broken!


I thought it was a fabulous idea, actually leaving the office on-time
(for a change), and heading straight down to the beach for some
wind-surfing...

That said, it really messed with your head. People staggered-in and
managed little output first-thing. (need I say more?)

At a more amusing level: my door was literally always-open, and because
my office was at the end of a corridor, colleagues required only a
glance to see if I was 'available'. The door only closed for
personal/confidential discussions or when I was 'out' - except during
Ramadan when I didn't want to insult anyone by drinking tea, effectively
in-public. So, when the door was closed for long periods, this confused
my staff. Indeed, I would often be asked "where have you been?" when I'd
been working-away at my desk all-along, but simply hadn't got up to open
the door once 'the coast was clear'. Life's rich tapestry...

In my case, I blame "Ramadan-hours" for 'flipping the switch' (in my
head) and turning a late-night owl, and stereotypical techie/hacker;
into an 'early bird'. Ironically such serves me well today - dealing
with clients and colleagues on the other side of the planet, who much
prefer me to wake-early, so that they don't have to interrupt their
evenings at home...
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list

On 01/09/2021 11.27, MRAB wrote:
> On 2021-08-31 23:31, Chris Angelico wrote:
>> On Wed, Sep 1, 2021 at 8:22 AM MRAB <python@mrabarnett.plus.com> wrote:
>>>
>>> [snip]
>>> In the EU, DST in the member states changes at the same time. It's not
>>> like the US where it ripples across the timezones, so the differences
>>> vary during the change. It all happens in one go.
>>>
>>
>> Ah, good to know. I think that actually makes a lot of sense; in the
>> US, they try to let everyone pretend that the rest of the world
>> doesn't exist ("we always change at 2AM"), but in Europe, they try to
>> synchronize for the convenience of commerce ("everyone changes at 1AM
>> UTC").
>>
>> A quick browse of Wikipedia suggests that some European countries
>> (outside of the EU, which mandates DST transitions) have constant
>> year-round UTC offsets. In theory, there could be a non-EU country
>> that observes DST with different dates, but I can't find any examples.
>> Here's hoping, hehe.
>>
> It goes forwards on the last Sunday of March and back on the last Sunday
> of October.

and @Chris' point about the lack of synchronisation:

«
Daylight saving starts each year at 2am on the last Sunday in September,
and ends at 3am on the first Sunday in April.

Daylight saving starts Daylight saving ends
26 September 2021 3 April 2022
»
https://www.govt.nz/browse/recreation-and-the-environment/daylight-saving/


Have learned something new about my adopted-country today! Apparently
New Zealand was once one of those half-hour-out countries (until 1946).
From when no "Daylight Saving time" was recognised. In 1974 a trial took
place, and after public debate, the idea extended - continuing today:
https://www.govt.nz/browse/recreation-and-the-environment/daylight-saving/history-of-daylight-saving-in-nz/


To explain the rationale for "Daylight Saving", ie "Summer Time":
«
The 2008 survey found that 82% of New Zealanders approved of the 2007
extension to the period of daylight saving time.

The rationale for changing the time over the summer months is that more
sunlight hours will fall in the early morning if standard time is
applied year round. In summer, these early morning sunlight hours are
seen as being wasted as many people are asleep at that time. If the
sunlight hours are shifted to the evening, by way of daylight saving
time, they are more useful.
»
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list

On Wed, 1 Sep 2021 11:19:03 +1200, dn via Python-list
<python-list@python.org> declaimed the following:


>time-zones. (Yes, you did say "CA", but easily 'missed' - by author and
>reader alike)

Or possibly misread as the Peoples Republic of CALIFORNIA <G> (even if
there isn't a "New Brunswick" in the PRCa)

Though https://roadsidethoughts.com/nb/lower-california-profile.htm
doesn't help in deconfusion <G>


--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

--
https://mail.python.org/mailman/listinfo/python-list

On Wed, 1 Sep 2021 09:38:30 +1000, Chris Angelico <rosuav@gmail.com>
declaimed the following:


>Yeah, I have no idea where the "farmers" explanation came from.
>Growing up, we had some friends in countrified areas, including a
>sheep farmer who showed us a ton of stuff about how shearing worked,
>how moronic sheep are, and how farming life actually operates. It's
>not uncommon for such people to have two clocks: Government Time and
>Sun Time. Like you say, no cow wears a watch!
>
Not only do the cattle not have timepieces -- but they probably expect
to be milked /n/-hours after the prior milking.

I think the DST was meant for industrialization -- factories wouldn't
have to run expensive artificial lighting for part of the day-shift; there
would be more natural light falling in through the south facing windows on
the roof of the building.


--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

--
https://mail.python.org/mailman/listinfo/python-list

On Tue, 31 Aug 2021 16:53:14 -0500, 2QdxY4RzWzUUiLuE@potatochowder.com
declaimed the following:

>On 2021-09-01 at 07:32:43 +1000,
>Chris Angelico <rosuav@gmail.com> wrote:
>> If we could abolish DST world-wide, life would be far easier. All the
>> rest of it would be easy enough to handle.
>
>Agreed.
>

Unfortunately, most of the proposals in the US seem to be that
/standard time/ would be abolished, and DST would rule year-round. Hence
putting the center of the time zone one hour off from solar mean noon;
which is what the time zones were originally based upon.


--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

--
https://mail.python.org/mailman/listinfo/python-list

On 31/08/2021 22:13, Chris Angelico wrote:

> But ultimately, it all just means that timezones are too hard for
> humans to handle, and we MUST handle them using IANA's database. It is
> the only way.

Except for the places that don't follow the IANA scheme and/or
dynamically change their time settings on a whim. To be complete
you need the ability to manually override too.

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


--
https://mail.python.org/mailman/listinfo/python-list