Hi Chris, Cameron. Well, let's say I specify the datetime 2022-02-22 02:02 (AM). I think everyone could agree that it also means 2022-02-22 02:02:00:00, to 2022-02-22 02:02:59:59.
And I think the same applies for a date. If the pipes are clogged and I can't take (give) a shit, a shower or do anything else involving fluids, I can just leave the keys under the doormat, and agree a date with the plumber, and go off to a friend of relatives' place for a couple of days while waiting for the plumber to do the necessary work. Usually that would imply that the plumber visits from 07:00 to 15:00 on the given date, with an implicit timezone. It could also mean that the plumber shows up at 01:00 at night and fixes it, or at 18:00 in the evening. If a newspaper talks about new years celebrations, and specifically talks about what happens on the 1st of January, this could mean at 00:01, or a later dinner party at 20:00. But the celebration that starts at midnight, doesn't start at the same moment all over the world. So context, or location and implicit timezone does matter. I was also thinking of specifying some range objects for my needs, as that makes sense from what I've worked with earlier, this makes sense for example for a month or a year (or even decade) as well. But the point is that a date is not just a flat, one-dimensional object. Regards, Morten On Sun, Feb 27, 2022 at 11:11 PM Chris Angelico <ros...@gmail.com> wrote: > On Mon, 28 Feb 2022 at 08:51, Cameron Simpson <c...@cskk.id.au> wrote: > > > > On 27Feb2022 11:16, Morten W. Petersen <morp...@gmail.com> wrote: > > >I was initially using the date object to get the right timespan, but > > >then > > >found that using the right timezone with that was a bit of a pain. So I > > >went for the datetime object instead, specifying 0 on hour, minute and > > >second. > > > > > >What's the thinking behind this with the date object? Wouldn't it be > nice > > >to be able to specify a timezone? > > > > This has come up before. My own opinion is that no, it would be a bad > > idea. You're giving subday resolution to an object which is inherently > > "days". Leaving aside the many complications it brings (compare two > > dates, now requiring timezone context?) you've already hit on the easy > > and simple solution: datetimes. > > > > I'd even go so far as to suggest that if you needed a timezone for > > precision, then dates are the _wrong_ precision to work in. > > > > I would agree. If you have timestamps and you're trying to determine > whether they're within a certain range, and timezones matter, then > your range is not days; it begins at a specific point in time and ends > at a specific point in time. Is that point midnight? 2AM? Start/close > of business? It could be anything, and I don't see a problem with > requiring that it be specified. > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list > -- I am https://leavingnorway.info Videos at https://www.youtube.com/user/TheBlogologue Twittering at http://twitter.com/blogologue Blogging at http://blogologue.com Playing music at https://soundcloud.com/morten-w-petersen Also playing music and podcasting here: http://www.mixcloud.com/morten-w-petersen/ On Google+ here https://plus.google.com/107781930037068750156 On Instagram at https://instagram.com/morphexx/ -- https://mail.python.org/mailman/listinfo/python-list
