Mailman 3 July 2015 - Datetime-SIG

Re: [Datetime-SIG] What's are the issues?
by Łukasz Rekucki 29 Jul '15

29 Jul '15

On 29 July 2015 at 19:37, Alexander Belopolsky <alexander.belopolsky(a)gmail.com> wrote: > On Wed, Jul 29, 2015 at 1:21 PM, Chris Barker <chris.barker(a)noaa.gov> wrote: >> But really does anyone really want to do the ugliness of trying to do time >> calculation completely in a time-zone, discontinuous, ugly as hell >> encoding???? > > Yes, if both the input and the output of your program contain temporal > data in the same timezone. > > For example, "Find a day with the largest trading volume on the New > York Stock Exchange in 2014." > > The exchange publishes its data in New York local time and you know > that trading hours are from 09:30 to 16:00 with a few exceptions that > are again published in the local time. The database is huge, so you > select the data by day, split it into chunks by 5 minutes, add up the > volumes for each day > and find maximum. Easy. No need to know when the DST transitions > were in New York in 2014. Got the same database from Paris? No need > to change your code. Now try to do the same in UTC. I think my > program will finish before you stop arguing what "a day" is. That's because your program does not need to be time zone aware *at all* (it works on Local Datetime). Everyone already agrees that this work. That doesn't mean that there are no other use cases. -- Łukasz Rekucki

1 0

Re: [Datetime-SIG] Actually, I'm out.
by Felipe Ochoa 29 Jul '15

29 Jul '15

> > maybe we can all take a breath and sleep on things. > This may be a bug in the timezone conversion, but over here on America/New_York, it's not even 2pm :-) Are you proposing adding a siesta module?

1 0

Re: [Datetime-SIG] What's are the issues?
by Alexander Belopolsky 29 Jul '15

29 Jul '15

On Wed, Jul 29, 2015 at 1:21 PM, Chris Barker <chris.barker(a)noaa.gov> wrote: > But really does anyone really want to do the ugliness of trying to do time > calculation completely in a time-zone, discontinuous, ugly as hell > encoding???? Yes, if both the input and the output of your program contain temporal data in the same timezone. For example, "Find a day with the largest trading volume on the New York Stock Exchange in 2014." The exchange publishes its data in New York local time and you know that trading hours are from 09:30 to 16:00 with a few exceptions that are again published in the local time. The database is huge, so you select the data by day, split it into chunks by 5 minutes, add up the volumes for each day and find maximum. Easy. No need to know when the DST transitions were in New York in 2014. Got the same database from Paris? No need to change your code. Now try to do the same in UTC. I think my program will finish before you stop arguing what "a day" is.

1 0

Re: [Datetime-SIG] What's are the issues?
by Łukasz Rekucki 29 Jul '15

29 Jul '15

On 29 July 2015 at 19:23, Alexander Belopolsky <alexander.belopolsky(a)gmail.com> wrote: > On Wed, Jul 29, 2015 at 1:05 PM, Lennart Regebro <regebro(a)gmail.com> wrote: >>> Not so. It can easily (albeit rarely) arise in cases of pure timezone >>> conversions. Conversions have nothing to do with arithmetic. If I >>> convert a time in zone X to a time in zone Y that lands in an >>> ambiguous span in zone Y, without the conversion _also_ setting an >>> is_dst flag in the destination, it's impossible to reliably convert >>> the time in zone Y back to zone X again. >> >> No, you just consistently pick one of the two times in both >> conversions to and from and it will roundtrip just fine. > > This may work when both conversions have an ambiguity, but in the real > life this does not happen. > > Assume the time difference between X and Y in 12 hours, and naturally > Y does not have a DST transition in the middle of the day. > > Let's start the conversion: > > "01:30 X/DST" -> "13:30 Y" -> "01:30 X/DST" > > So far so good. We ignore DST in the first transition, get > unambiguous time in the Y zone and get the original X time in the > second transition. > > However, we we start with "01:30 X/STD", we must get > > "01:30 X/STD" -> "13:30 Y" I think I'm lost at this point. Assume Y = UTC (fulfills all your assumptions for some -12 zone). Why would 01:30 X/DST and 01:30 X/STD convert to the same point in time ? -- Łukasz Rekucki

1 0

Re: [Datetime-SIG] Actually, I'm out.
by Guido van Rossum 29 Jul '15

29 Jul '15

Surely some people understand some of the issues. I've seen a lot of communication failures, many exacerbated by people trying to post quickly (hoping against reason to stay on top of the thread :-). I've sent Lennart a message off-line asking him to reconsider. In the mean time maybe we can all take a breath and sleep on things. I believe there is a way out, but we first need to stop the bleeding. On Wed, Jul 29, 2015 at 7:09 PM, Lennart Regebro <regebro(a)gmail.com> wrote: > I spent two half days on this already, and I don't believe that people > don't understand the issue by now, since I've repeated it five million > times. And repeating it over and over just makes me depressed. > > I'm out. > > I'll solve this issue my own way, by myself. > > Regards > Lennart > _______________________________________________ > Datetime-SIG mailing list > Datetime-SIG(a)python.org > https://mail.python.org/mailman/listinfo/datetime-sig > The PSF Code of Conduct applies to this mailing list: > https://www.python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido)

1 0

Re: [Datetime-SIG] What's are the issues?
by Alexander Belopolsky 29 Jul '15

29 Jul '15

On Wed, Jul 29, 2015 at 1:05 PM, Lennart Regebro <regebro(a)gmail.com> wrote: >> Not so. It can easily (albeit rarely) arise in cases of pure timezone >> conversions. Conversions have nothing to do with arithmetic. If I >> convert a time in zone X to a time in zone Y that lands in an >> ambiguous span in zone Y, without the conversion _also_ setting an >> is_dst flag in the destination, it's impossible to reliably convert >> the time in zone Y back to zone X again. > > No, you just consistently pick one of the two times in both > conversions to and from and it will roundtrip just fine. This may work when both conversions have an ambiguity, but in the real life this does not happen. Assume the time difference between X and Y in 12 hours, and naturally Y does not have a DST transition in the middle of the day. Let's start the conversion: "01:30 X/DST" -> "13:30 Y" -> "01:30 X/DST" So far so good. We ignore DST in the first transition, get unambiguous time in the Y zone and get the original X time in the second transition. However, we we start with "01:30 X/STD", we must get "01:30 X/STD" -> "13:30 Y" by the first rule and have no choice but follow with "13:30 Y" -> "01:30 X/DST" and the round-trip mutates STD to DST. The only way to solve it is to take into account the "STD" marker in the first transition and map "01:30 X/STD" -> "14:30 Y" -> "01:30 X/STD", but you cannot take into account the "STD" marker if it is not there to begin with.

1 0

Re: [Datetime-SIG] What's are the issues?
by Chris Barker 29 Jul '15

29 Jul '15

On Wed, Jul 29, 2015 at 10:05 AM, Lennart Regebro <regebro(a)gmail.com> wrote: > On Wed, Jul 29, 2015 at 7:00 PM, Tim Peters <tim.peters(a)gmail.com> wrote: > > is_dst remains necessary to distinguish between ambiguous local times, > > just as Chris states: > > But with the current implementations, those do not exist. datetime > explicitly and intentionally assume that 1 day always is 24 hours. > Hence, in the datetime universe, local times can not be ambiguous, of course they can (and we really ned antoher word -- again, using "day" to mean two totally different things). but anyway -- sorry I used teh term "round trip" that isn't quite what I meant. What I meant was: "know what location on the time continuum a particular calendar time represents" (note that this is more or less convert to UTC) that can be ambiguous in a DST transition without an is_dst flag. So if you want to handle time zones with DST (and go both ways), you need an is_dst flag. and that has nothign to do with artihmetic or calendar operations -- but yes, it's is about conversion. But really does anyone really want to do the ugliness of trying to do time calculation completely in a time-zone, discontinuous, ugly as hell encoding???? I think not -- which mean you can't do squat without converting to-from a clean representation i.e. UTC. So I say step one is to fully support time zones and the ability to do "real" time arithmetic and conversion to-from UTC. Then it's another task to support calendar operations. Or does something think we really need to be able to compute "this time tomorrow", but not "24 hours from now"? -Chris > > > Not so. It can easily (albeit rarely) arise in cases of pure timezone > > conversions. Conversions have nothing to do with arithmetic. If I > > convert a time in zone X to a time in zone Y that lands in an > > ambiguous span in zone Y, without the conversion _also_ setting an > > is_dst flag in the destination, it's impossible to reliably convert > > the time in zone Y back to zone X again. > > No, you just consistently pick one of the two times in both > conversions to and from and it will roundtrip just fine. > > //Lennart > -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker(a)noaa.gov

1 0

Actually, I'm out.
by Lennart Regebro 29 Jul '15

29 Jul '15

I spent two half days on this already, and I don't believe that people don't understand the issue by now, since I've repeated it five million times. And repeating it over and over just makes me depressed. I'm out. I'll solve this issue my own way, by myself. Regards Lennart

1 0

Re: [Datetime-SIG] What's are the issues?
by Lennart Regebro 29 Jul '15

29 Jul '15

On Wed, Jul 29, 2015 at 7:00 PM, Tim Peters <tim.peters(a)gmail.com> wrote: > is_dst remains necessary to distinguish between ambiguous local times, > just as Chris states: But with the current implementations, those do not exist. datetime explicitly and intentionally assume that 1 day always is 24 hours. Hence, in the datetime universe, local times can not be ambiguous, > Not so. It can easily (albeit rarely) arise in cases of pure timezone > conversions. Conversions have nothing to do with arithmetic. If I > convert a time in zone X to a time in zone Y that lands in an > ambiguous span in zone Y, without the conversion _also_ setting an > is_dst flag in the destination, it's impossible to reliably convert > the time in zone Y back to zone X again. No, you just consistently pick one of the two times in both conversions to and from and it will roundtrip just fine. //Lennart

1 0

Re: [Datetime-SIG] What's are the issues?
by Tim Peters 29 Jul '15

29 Jul '15

Have to hit-and-run here (out of time for this for a while): [Chris Barker] >> Huh? Now I'm really confused. IIUC, the is_dst flag is required in order to >> be able to round-trip between UTC and local_time representations. [Lennart Regebro] > No, that's not necessary. It's necessary to disambiguate between > ambiguous datetimes, but you can, like dateutils implementation, > simply just pick one consistently, and you can round-trip. is_dst remains necessary to distinguish between ambiguous local times, just as Chris states: >> In particular, so the API can support specifying a datetime in a time zone >> that "happens" twice without ambiguity. > Yes, but that has now been declared as not desired. News to me ;-) > We no longer want datetime to be able to do that. Of course we do.; Well, some people do ;-) > That's only a feature you need or even can have if you want to do > real time arithmetic over DST changes. Not so. It can easily (albeit rarely) arise in cases of pure timezone conversions. Conversions have nothing to do with arithmetic. If I convert a time in zone X to a time in zone Y that lands in an ambiguous span in zone Y, without the conversion _also_ setting an is_dst flag in the destination, it's impossible to reliably convert the time in zone Y back to zone X again. Note that it's quite possible the time we started with was not ambiguous in X's zone, so without is_dst to tell us which zone-Y time was intended, the conversion back to zone X may be dead wrong (from X's POV). Note that ambiguities are also possible in timezones where the _base_ ("standard") UTC offset changes over time. The default conversion methods currently ignore such possibilities. There have already been many other messages suggesting that, because of this, "is_dst" may be a poor name for the bit of information required, [and skipping the rest for now because I'm more than out of time now ;-)\

1 0