When the clocks change, don't you shift timezone? There aren't duplicate times in BST, we just switch from GMT to BST and then back.
In these situations, the information displayed on a local clock (or stored in a Python datetime instance) is insufficient to identify a particular moment in time.
Does the datetime instance not store the timezone?
You are always in the same time zone but the zone time changes. BST and GMT are not time zones - time zones are (usually) named by geographic features like large cities and is Europe/London in your case - but zone times. Therefore when entering or leaving daylight saving time you remain in the same time zone but the zone time of your time zone changes.
It would be nice if those two things which have an important but very subtle distinction had names which were not just the reverse of each other. It seems like despite you explaining this, it would be very easy for one to mistake "zone time" for "time zone".
Isn't it about summer and winter time? I'm pretty sure you're still in the same timezone in those cases.
That said, I don't see the reason for this PEP. You should only store a value in the DB that doesn't change like that, and then when displayed you can change it to fit the local time of the user.
In Britian during the summer we use the BST timezone and during winter we use GMT.
But once again this is one of those "assumptions about time that everyone gets wrong" just because we shift timezones in Britian doesn't necessarily mean that people in other countries do the same - they might just change what the timezone offset is and keep the timezone the same.
Another great resource is the tz database [0].
It includes some great vignettes as well as the time zone rules:
From Larry M. Smith (2006-04-26) re Wisconsin:
http://www.legis.state.wi.us/statutes/Stat0175.pdf ...
is currently enforced at the 01:00 time of change. Because the local "bar time" in the state corresponds to 02:00, a number of citations are issued for the "sale of class 'B' alcohol after prohibited hours" within the deviated hour of this change every year....
From Winston Churchill (1934-04-28):
It is one of the paradoxes of history that we should owe the boon of summer time, which gives every year to the people of this country between 160 and 170 hours more daylight leisure, to a war which plunged Europe into darkness for four years, and shook the foundations of civilization throughout the world.
That's not the way it works in the US at all. We keep the same zone all year long but change the offset and change the name slightly. The zones are geographically based: Eastern, Central, Mountain, and Pacific. They are abbreviated differently depending on whether Daylight Saving is in effect or not, for example Central is either CST (Standard, -06:00) or CDT (Daylight, -05:00).
The important part here is that the API to get a timezone usually doesn't include a Daylight Saving flag. For example pytz would be used as pytz.timezone('US/Central'). There needs to be a process that adjusts the tzinfo object to the proper offset; in pytz this is the localize method, but that's non-standard.
Isn't that just a matter of having your library differentiate the timezones slightly,even if the canonical name is identical for the two different timezones (no matter what the country calls them, they really are different)? Additionally, there are ways to reference the timezone in the local time that are guaranteed to be unique. For example, offset from UTC. 1:15 AM UTC-09 is not the same as 1:15 AM UTC-08.
What localities do you know of that just change the hour and do not have a time zone assigned to deal with it? I'm fairly sure the point of time zones it to track all those changes, and a name would be assigned to deal with it.
But once again this is one of those "assumptions about time that everyone gets wrong" just because we shift timezones in Britian doesn't necessarily mean that people in other countries do the same - they might just change what the timezone offset is and keep the timezone the same.
Well, for a proposed change I'd like to see examples of the actual problem caused. The only example I can see is EST and EDT, which seems to be the same as the UK doing GMT->BST. Same for Andorra.
My question wasn't rhetorical, I was actually asking if there were places that don't do this.
Yes, you could get the information from the timezone, but how would one do that in code?
The only time that one has the time fold is when you turn the clock backward (let's just call that shifting from daylight savings to standard timezone). And this would only affect code which used wall clock time (time as it's read, e.g. 1:30am PDT), and would also only affect code which wanted to run something only once at a time within that fold (e.g. 1:30am ... not on both 1:30am's).
So, using the timezone method, just check to see if your current 1:30am is in your daylight savings timezone. Hurray! You're in the clear. Go ahead and do that thing you wanted to do only on the first 1:30am.
But the next day you're going to run into a problem. The only 1:30am you're going to get is in the standard timezone. So now you have to check for this timezone change only on the day of the change, which is yet another piece of data you have to keep track of. On the day of the change, do this timezone comparison, and on every other day don't worry about it.
When the clock hits your interesting time of 1:30am, just check to see if today is the day of the change, check what the current timezone is, check what the daylight savings time zone is, check to see if those those two values are the same, and now do your thing. Otherwise, just do your thing.
All of the above also ignores that people change times at different times (11pm, 1am, 2am, 3am), some don't change a full hour, and some don't change at all.
The proposal gets rid of all of that convoluted logic in everyone's programs, and instead it provides a single boolean value: is this the second time I've seen this time because of daylight savings shenanigans.
Comments
When the clocks change, don't you shift timezone? There aren't duplicate times in BST, we just switch from GMT to BST and then back.
Does the datetime instance not store the timezone?
You are always in the same time zone but the zone time changes. BST and GMT are not time zones - time zones are (usually) named by geographic features like large cities and is Europe/London in your case - but zone times. Therefore when entering or leaving daylight saving time you remain in the same time zone but the zone time of your time zone changes.
It would be nice if those two things which have an important but very subtle distinction had names which were not just the reverse of each other. It seems like despite you explaining this, it would be very easy for one to mistake "zone time" for "time zone".
Isn't it about summer and winter time? I'm pretty sure you're still in the same timezone in those cases.
That said, I don't see the reason for this PEP. You should only store a value in the DB that doesn't change like that, and then when displayed you can change it to fit the local time of the user.
In Britian during the summer we use the BST timezone and during winter we use GMT.
But once again this is one of those "assumptions about time that everyone gets wrong" just because we shift timezones in Britian doesn't necessarily mean that people in other countries do the same - they might just change what the timezone offset is and keep the timezone the same.
Absolutely agree with the "one of those assumptions" bit. See http://infiniteundo.com/post/25326999628/falsehoods-programm... for a great list.
(And related, see https://www.mjt.me.uk/posts/falsehoods-programmers-believe-a... for more about addresses.)
Another great resource is the tz database [0]. It includes some great vignettes as well as the time zone rules:
From Larry M. Smith (2006-04-26) re Wisconsin: http://www.legis.state.wi.us/statutes/Stat0175.pdf ... is currently enforced at the 01:00 time of change. Because the local "bar time" in the state corresponds to 02:00, a number of citations are issued for the "sale of class 'B' alcohol after prohibited hours" within the deviated hour of this change every year....
From Winston Churchill (1934-04-28): It is one of the paradoxes of history that we should owe the boon of summer time, which gives every year to the people of this country between 160 and 170 hours more daylight leisure, to a war which plunged Europe into darkness for four years, and shook the foundations of civilization throughout the world.
[0] http://www.iana.org/time-zones
That's not the way it works in the US at all. We keep the same zone all year long but change the offset and change the name slightly. The zones are geographically based: Eastern, Central, Mountain, and Pacific. They are abbreviated differently depending on whether Daylight Saving is in effect or not, for example Central is either CST (Standard, -06:00) or CDT (Daylight, -05:00).
The important part here is that the API to get a timezone usually doesn't include a Daylight Saving flag. For example pytz would be used as pytz.timezone('US/Central'). There needs to be a process that adjusts the tzinfo object to the proper offset; in pytz this is the localize method, but that's non-standard.
Isn't that just a matter of having your library differentiate the timezones slightly,even if the canonical name is identical for the two different timezones (no matter what the country calls them, they really are different)? Additionally, there are ways to reference the timezone in the local time that are guaranteed to be unique. For example, offset from UTC. 1:15 AM UTC-09 is not the same as 1:15 AM UTC-08.
What localities do you know of that just change the hour and do not have a time zone assigned to deal with it? I'm fairly sure the point of time zones it to track all those changes, and a name would be assigned to deal with it.
Well, for a proposed change I'd like to see examples of the actual problem caused. The only example I can see is EST and EDT, which seems to be the same as the UK doing GMT->BST. Same for Andorra.
My question wasn't rhetorical, I was actually asking if there were places that don't do this.
Yes, you could get the information from the timezone, but how would one do that in code?
The only time that one has the time fold is when you turn the clock backward (let's just call that shifting from daylight savings to standard timezone). And this would only affect code which used wall clock time (time as it's read, e.g. 1:30am PDT), and would also only affect code which wanted to run something only once at a time within that fold (e.g. 1:30am ... not on both 1:30am's).
So, using the timezone method, just check to see if your current 1:30am is in your daylight savings timezone. Hurray! You're in the clear. Go ahead and do that thing you wanted to do only on the first 1:30am.
But the next day you're going to run into a problem. The only 1:30am you're going to get is in the standard timezone. So now you have to check for this timezone change only on the day of the change, which is yet another piece of data you have to keep track of. On the day of the change, do this timezone comparison, and on every other day don't worry about it.
When the clock hits your interesting time of 1:30am, just check to see if today is the day of the change, check what the current timezone is, check what the daylight savings time zone is, check to see if those those two values are the same, and now do your thing. Otherwise, just do your thing.
All of the above also ignores that people change times at different times (11pm, 1am, 2am, 3am), some don't change a full hour, and some don't change at all.
The proposal gets rid of all of that convoluted logic in everyone's programs, and instead it provides a single boolean value: is this the second time I've seen this time because of daylight savings shenanigans.
Does it? It doesn't cover the scheduling problem the other half of the year when the clocks move the other direction.
If running a job twice is a problem, then why not check that the job has not already been run?
Is this unambiguous? If it's 2015-10-25-01-30-00 GMT, have I seen that time before? In the UK, yes, in Mali no.
You don't need to do any of that. Just get a unixtime, and move on.
Why are you doing time math in local time?
Simply do all the time math in universal time and be done with it.