Here in the Netherlands, the analog cut-off already happened last year (december 2006).
The only money the government spent was on a publicity campaign to let everyone know beforehand that this was going to happen. (of course, people ran to the shops only in the weekend analog was switched off, so there was a stock problem anyway)
Everyone had to buy his or her own digital box. The reasoning is that you bought your own TV, so why should the government be responsible to keep it uptodate with the advances of technology? You did not get a free color TV upgrade when color transmission started either...
Of course the analog transmitters had to be replaced by digital, but because of the lower power and multiple programs per carrier there was a running cost reduction. And these days the investments in transmitters are made by independent operating companies that get paid per transmitted program per year.
It depends on the transmission network. When they just replaced the old analog transmitters with digital transmitters (probably with 10 times less power) on the same elevated locations, this could be true.
However, a digital network (at least one that uses OFDM) can be structured differently: instead of powerful transmitters covering a large area, you can use many smaller transmitters covering only a small city or part of a larger city, kind of like cellphone. With that method, indoor reception is much more feasible than with the old analog network, especially when you do not happen to be close to a classic transmitter location.
With that reasoning, you could argue that there should not be a filesystem and everything on a computer should be in a database.
Lots of people, including Microsoft, have claimed that in the past. Few have been successful in actually implementing it (IBM S/38?).
Of course, a database implemented as a big file with internal structure will have internal fragmentation just like data stored in a number of smaller files can lead to fragmentation of the filesystem. Here you are just comparing the quality of the filesystem vs. what someone may have implemented in a particular database.
However, in practice the integrity of a filesystem, which is modified only by the kernel, is usually better protected than the internal structure of a file which some user-mode application sees and modifies as if it were a database.
mbox is a file format for a single folder. when you have an inbox, sent-mail, trash and some saved-mail folders you will have several mbox files. when you receive a mail and your inbox is deleted, you "only" lose the recently received mails and not all those valuable mails you saved in the past.
Maybe it wasn't such a good idea to put all mail, including not only INBOX but also all extra folders, in a single file? At least other MUAs usually have a separate file for each folder.
Also, many IT pros may be occupied with the switch to daylight saving time, which at the behest of Congress, is happening three weeks earlier this year.
As a European, what mostly occupies me is deleting all those "field notices" that Cisco mails me about the DST issue. It looks like they send a separate mail for every product they sell and have ever sold, telling me that it needs to be patched. Not all on a single day or all in a single mail, but spread over a month time. And the profiles that you can define for the kind of notices you want to receive by mail does not allow the selection of an affected region, or to remove field notices about some specific subject.
Well, you have to have something to complain about...
Here at home, at the office and at my co-located server I'm running both IPv6 as well as IPv4. If a remote computer supports IPv6 it will be automatically used, otherwise IPv4 will be used.
I have done that for a while. It is 4 years ago, and maybe things have improved since then, but it was not as problem-free as you suggest. (e.g. systems with IPv6 entries in DNS that were not actually reachable caused long delays before IPv4 was selected instead) I do not consider dual-stack a viable migration path for a billion existing systems on the net.
it's even possible to do transparent IPv6 IPv4 translation.
This is the only way to go, but it should have been included in all IPv6 specs and stacks from day 1. By now, every new system and network device sold should have been an IPv6 device operating in IPv4 compatible mode and/or performing translation as necessary (given by its position in the network). Then, you could consider phasing out IPv4 one technical lifetime cycle from now (which would be 5-7 years at least when you include home users etc). This has not happened, so that phaseout is not going to happen either. Another solution will have to be found instead.
There will be backpressure. It could mean the price goes up, it could mean the rules to get addresses get more strict, whatever. There could be other solutions. We will see. I just don't believe that the "burn everything behind us and build a new structure" way (IPv6) will win.
So, what is the solution to all of this? Move to a larger address space!
Sure. But not in the way it is proposed now. Think about how the 64kbytes limit of 8/16 bit processors was solved. Segmentation, paging, extended instructions that use larger addresses, etc.
Our current 64bit processors can still run 32bit code. The 32bit processors can run 16bit code. The 16bitters could almost run programs written for their 8bit predecessors. The Internet needs something similar. The PowerPC processor does not replace the Intel x86 line in PCs because it is not compatible. It does not matter if it uses less power, has smaller silicon, is cheaper to produces and whatever advantages you can come up with. It does not run existing programs so it is completely impractical to switch, save in some niche markets. Same thing when changing the Internet protocol.
I don't see any reason why I can't be behind an IPV4 NAT AND have a public IPV6 address. At the same time.
What you are saying is that you can run two parallel Internets at the same time, and expect everyone else to do so, and then phase out the old Internet once that parallel phase is completed.
This is of course completely impractical. Not going to happen. A new protocol has only got a chance when people using the new protocol can talk to those running the old protocol in a "fallback mode" or using some widely available translation.
My ISP has been offering IPv6 addresses for several years. In fact I have applied for "one" and experimented with it in 2002. (I write "one" because I actually got a/60 network assigned, or 2^68 addresses).
It worked. I could see some turtle dancing on a website that showed only a static turtle to IPv4 visitors. Hooray. Other than that, it only caused trouble. Every DNS lookup was performed twice, once for IPv6 and once for IPv4. There were systems that offered an IPv6 reply in DNS but were not actually online in IPv6, causing long delays and errors. My firewall did not support IPv6, leaving me hoping that hackers would not have made the switch yet. When I upgraded to a newer Linux version I did not bother to make it working again.
For me as an techie user there were no visible advantages, and it caused problems. No need to explain what it would mean to the average user at home, the ones that we want to switch because "we are running out of addresses". When they cannot be migrated to IPv6 smoothly and without causing more problems than the typical ISP helpdesk can handle today with IPv4, it simply ain't going to happen.
What I mean is that when the clock is offset from solar time, people will shift their workday accordingly.
I don't know what is customary in your country, but here it is normal to have a 7.5 hour working day that one can start and end in a 2-hour interval at the beginning and end of the day. So there is nothing that prevents you from working half an hour earlier when you want to go running after work, or half an hour later when you don't.
You are blindly assuming that the only possible change in the Internet is continued growth, the only possible event is running out of addresses, and the only solution is change to IPv6.
I am not so convinced. Because there is no compatibility between IPv4 and IPv6, there is no migration path. You can deploy IPv6 in your organization, but you will not be able to communicate with anyone except those that also made the bold move to do the same. The vast majority of the existing Internet is unreachable. That is not a viable path to migrate the current Internet to a new protocol.
I think this is a vital mistake. Either yet another new IP version will be developed inside the Internet community that *does* allow a seamless migration, or something else will develop (as has happened so often in computing) that will replace the Internet. Maybe a commercial development by parties that have big financial interests, maybe something sponsored by governments and focussed more on identification and accountability of its users.
It is often apparent that IPv6 advocates believe that IPv4 is a dead end and it will inevitably be replaced by IPv6. But that is similar to people in the eighties claiming that everything will be ISO-OSI. Did not happen either.
There is no reason to believe that 170 million addresses will be allocated each year until the available number suddenly drops to zero, at which moment the address shop closes and new applicants stand outside with no way to connect.
If you think it will work like that, just observe what happens with some other scarce resource that nears depletion.
I'm about 10 degrees west of the center of our timezone (that in itself is funny, because timezones are supposed to be center plus or minus 7.5 degrees). In winter, our clock time is 40 minutes ahead of solar time. In summer it is one hour and 40 minutes.
Again, it is a matter of habit. We changed to this system in world war 2 and it never changed back. Most people alive today don't have a reference to "the correct situation". Except, when we travel and are astonished how early it gets dark.
Light conditions vs clock time really does not matter a lot. People adapt to the static offset (40 minutes in our case). The DST just adds to that.
It is typical American. When the DST rules changed here in Europe a decade ago, nobody made any fuss about it. Microsoft did not even release a fix that would handle the future rule change, one was forced to apply a patch at the correct time. Linux of course was not affected, it already had a reasonable TZ library back then.
Most people with such firm opinions/statements about the time of sunset do not realise that this whole thing is very much dependent on your latitude.
When you live at 30deg north the situation is completely different from here (at 52deg north), which is again very different from 65deg north.
Here, it is very normal to drive both to and from work in darkness in winter. But, in summer it never gets (astronomically) dark the entire night. We are completely used to that. You would be too, if you lived in such a location.
Timezone borders are not simple lines (meridians) but follow local state borders. So there is no simple formula to convert position to timezone.
An NTP server (or client) does not know its position so it cannot do this easily. It could be done in a GPS receiver server like gpsd. However, for a practical implementation that does not cause more problems than it solves, it would have to contact an external server on Internet to perform the actual lookup.
It *is* how Microsoft did it, however they goofed at writing the conversion routines and made them much more primitive than posix timezone handling like in Linux. That is what you are paying for now.
That is the idea of building blocks. You know what external effect they have, but the internal workings are more complex and not necessarily one requires knowledge of the internal workings to use the building block. When I was a kid, those kits had only about 20 projects in the box and it contained transistors, resistors, capacitors, etc. You would build a blinking light, a morse code tone generator, stuff like that. The most complex kit would build an AM radio.
With opamps and digital ICs you can build more different and more complex things, but this means you understand less of the basic workings. An op-amp should only be looked at as a differential amplifier, and a NAND gate has some logic function, but how it is internally constructed out of transistors and resistors is less of a topic.
Ok, that confirms that Microsoft only implemented that "Dynamic DST" thing once it affected their own home country.
The KB article describes an entry for Israel that clearly needed dynamic DST at least since 2004, but on a Windows XP SP2 system patched with all critical and many non-critical hotfixes not including the DST fix there is no sign of Dynamic DST records.
The similar functionality in Linux already worked when the DST changed here back in 1996. And I think it was in place when I first installed Linux in december 1992. (I worked with Unix systems before that, and they had either US-hardwired DST or a configurable DST similar to Windows, with only one-year scope)
One difference between a zoneinfo system and some other systems is that you can update the zoneinfo file long before the actual change. There is no need to patch it in the months before the change, it can be done years before (assuming the upcoming change has been decided).
So, you can patch your system in february 2006 for a DST change that will take effect in march 2007. The system will probably be rebooted after the patch and before it becomes critical. You only need a reboot just before the DST date, on the systems that were not rebooted after you patched.
Has this been fixed with the release of Windows XP, or is this a new fix now that the problem affects the US? We have had several timezone rule changes in Europe, and Windows has never kept history here. And looking in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\TimeZoneInformation on an XP system I still don't see any.
Early Unix systems had fixed DST changeover, which was later (System V) changed to a configurable method similar to Windows. However, open source systems have used a "zoneinfo" system for at least 15 years now. I think commercial Unix systems have switched as well. Zoneinfo has a database of DST changeover moments in history, even (far) further back than its own creation. So UTC timestamps can be translated to local time for a wide range of dates, not only this year or even this half-year.
When the DST rules changed in Europe in 1996 I had no problems on my Linux system. Windows95 had to be patched, even though this change was known when it was released the year before. But the release was during DST so the patch could not yet be applied then, it had to wait until winter. The Linux zoneinfo files already had the new rule for quite some time, so no need to patch.
During our Y2K preparation a standard test was used on PC systems. Some Compaq systems failed and had to be replaced by decree.
However, they worked fine for many years after. The only thing that failed was the changeover from 1999-12-31 23:59:59 to 2000-01-01 00:00:00 but that was no problem as the loginscript set the clock anyway. But management only looked at the outcome of some "authorative" test that said FAIL.
The reason that nothing catastrophic happened was not only that everyone was well prepared, but also that the probability of a catastrophe was so much over-estimated. (similar to what is written into the abstract at the top of this article)
When nothing had been done about Y2K, surely there might have been some problems. But I don't think that we would have found all planes falling out of the sky, all electricity plants failing, all articles in stores evaporating as if by magic (because their sell-by date was wrong), etc.
Computer "experts" like to think that computers entirely rule the world and there is no human decision factor left. But that just isn't realistic. Even when all articles in the store are past their sell-by date, it is unlikely that the store personnel will discard everything just because of that. And when the computer says "8 o'clock" while the consumer's watch says "9 o'clock" there similarly is little chance of the world coming to an end.
When you are so careful about file timestamps, you should know that Windows does not translate them correctly anyway. Windows has no knowledge about timezone history. It translates the UTC time to local time using its current time-offset, which depends on the current DST status only. So, when you now look at a file timestamp (in the GUI) that you created last summer, you will find that its time is one hour off.
Even when Microsoft would finally fix this (they consider it a feature rather than a bug), they would probably not fix the historic aspect. I.e. now that the beginning of DST shifts one month, and you would look at a file created last year in that one month window, it would probably still be off.
Timezone handling in Windows just sucks. It does not have to be that bad, it works fine in Linux (including historic changes). Microsoft just has decided to make a bad implementation and then never fix it, in the name of backward compatability.
Slashdot Mirror
Here in the Netherlands, the analog cut-off already happened last year (december 2006).
The only money the government spent was on a publicity campaign to let everyone know beforehand that this was going to happen.
(of course, people ran to the shops only in the weekend analog was switched off, so there was a stock problem anyway)
Everyone had to buy his or her own digital box. The reasoning is that you bought your own TV, so why should the government be responsible to keep it uptodate with the advances of technology? You did not get a free color TV upgrade when color transmission started either...
Of course the analog transmitters had to be replaced by digital, but because of the lower power and multiple programs per carrier there was a running cost reduction.
And these days the investments in transmitters are made by independent operating companies that get paid per transmitted program per year.
It depends on the transmission network.
When they just replaced the old analog transmitters with digital transmitters (probably with 10 times less power) on the same elevated locations, this could be true.
However, a digital network (at least one that uses OFDM) can be structured differently: instead of powerful transmitters covering a large area, you can use many smaller transmitters covering only a small city or part of a larger city, kind of like cellphone.
With that method, indoor reception is much more feasible than with the old analog network, especially when you do not happen to be close to a classic transmitter location.
With that reasoning, you could argue that there should not be a filesystem and everything on a computer should be in a database.
Lots of people, including Microsoft, have claimed that in the past. Few have been successful in actually implementing it (IBM S/38?).
Of course, a database implemented as a big file with internal structure will have internal fragmentation just like data stored in a number of smaller files can lead to fragmentation of the filesystem. Here you are just comparing the quality of the filesystem vs. what someone may have implemented in a particular database.
However, in practice the integrity of a filesystem, which is modified only by the kernel, is usually better protected than the internal structure of a file which some user-mode application sees and modifies as if it were a database.
mbox is a file format for a single folder. when you have an inbox, sent-mail, trash and some saved-mail folders you will have several mbox files.
when you receive a mail and your inbox is deleted, you "only" lose the recently received mails and not all those valuable mails you saved in the past.
Maybe it wasn't such a good idea to put all mail, including not only INBOX but also all extra folders, in a single file?
At least other MUAs usually have a separate file for each folder.
Also, many IT pros may be occupied with the switch to daylight saving time, which at the behest of Congress, is happening three weeks earlier this year.
As a European, what mostly occupies me is deleting all those "field notices" that Cisco mails me about the DST issue. It looks like they send a separate mail for every product they sell and have ever sold, telling me that it needs to be patched. Not all on a single day or all in a single mail, but spread over a month time.
And the profiles that you can define for the kind of notices you want to receive by mail does not allow the selection of an affected region, or to remove field notices about some specific subject.
Well, you have to have something to complain about...
Here at home, at the office and at my co-located server I'm running both IPv6 as well as IPv4.
If a remote computer supports IPv6 it will be automatically used, otherwise IPv4 will be used.
I have done that for a while. It is 4 years ago, and maybe things have improved since then, but it was not as problem-free as you suggest.
(e.g. systems with IPv6 entries in DNS that were not actually reachable caused long delays before IPv4 was selected instead)
I do not consider dual-stack a viable migration path for a billion existing systems on the net.
it's even possible to do transparent IPv6 IPv4 translation.
This is the only way to go, but it should have been included in all IPv6 specs and stacks from day 1.
By now, every new system and network device sold should have been an IPv6 device operating in IPv4 compatible mode and/or performing translation as necessary (given by its position in the network).
Then, you could consider phasing out IPv4 one technical lifetime cycle from now (which would be 5-7 years at least when you include home users etc).
This has not happened, so that phaseout is not going to happen either. Another solution will have to be found instead.
There will be backpressure. It could mean the price goes up, it could mean the rules to get addresses get more strict, whatever.
There could be other solutions. We will see. I just don't believe that the "burn everything behind us and build a new structure" way (IPv6) will win.
So, what is the solution to all of this? Move to a larger address space!
Sure. But not in the way it is proposed now.
Think about how the 64kbytes limit of 8/16 bit processors was solved. Segmentation, paging, extended instructions that use larger addresses, etc.
Our current 64bit processors can still run 32bit code. The 32bit processors can run 16bit code. The 16bitters could almost run programs written for their 8bit predecessors.
The Internet needs something similar. The PowerPC processor does not replace the Intel x86 line in PCs because it is not compatible. It does not matter if it uses less power, has smaller silicon, is cheaper to produces and whatever advantages you can come up with. It does not run existing programs so it is completely impractical to switch, save in some niche markets.
Same thing when changing the Internet protocol.
Funny, my NIC seems to understand both just fine.
/60 network assigned, or 2^68 addresses).
This is completely irrelevant.
I don't see any reason why I can't be behind an IPV4 NAT AND have a public IPV6 address. At the same time.
What you are saying is that you can run two parallel Internets at the same time, and expect everyone else to do so, and then phase out the old Internet once that parallel phase is completed.
This is of course completely impractical. Not going to happen. A new protocol has only got a chance when people using the new protocol can talk to those running the old protocol in a "fallback mode" or using some widely available translation.
My ISP has been offering IPv6 addresses for several years. In fact I have applied for "one" and experimented with it in 2002.
(I write "one" because I actually got a
It worked. I could see some turtle dancing on a website that showed only a static turtle to IPv4 visitors. Hooray.
Other than that, it only caused trouble. Every DNS lookup was performed twice, once for IPv6 and once for IPv4. There were systems that offered an IPv6 reply in DNS but were not actually online in IPv6, causing long delays and errors. My firewall did not support IPv6, leaving me hoping that hackers would not have made the switch yet. When I upgraded to a newer Linux version I did not bother to make it working again.
For me as an techie user there were no visible advantages, and it caused problems. No need to explain what it would mean to the average user at home, the ones that we want to switch because "we are running out of addresses". When they cannot be migrated to IPv6 smoothly and without causing more problems than the typical ISP helpdesk can handle today with IPv4, it simply ain't going to happen.
What I mean is that when the clock is offset from solar time, people will shift their workday accordingly.
I don't know what is customary in your country, but here it is normal to have a 7.5 hour working day that one can start and end in a 2-hour interval at the beginning and end of the day. So there is nothing that prevents you from working half an hour earlier when you want to go running after work, or half an hour later when you don't.
You are blindly assuming that the only possible change in the Internet is continued growth, the only possible event is running out of addresses, and the only solution is change to IPv6.
I am not so convinced.
Because there is no compatibility between IPv4 and IPv6, there is no migration path. You can deploy IPv6 in your organization, but you will not be able to communicate with anyone except those that also made the bold move to do the same. The vast majority of the existing Internet is unreachable. That is not a viable path to migrate the current Internet to a new protocol.
I think this is a vital mistake. Either yet another new IP version will be developed inside the Internet community that *does* allow a seamless migration, or something else will develop (as has happened so often in computing) that will replace the Internet. Maybe a commercial development by parties that have big financial interests, maybe something sponsored by governments and focussed more on identification and accountability of its users.
It is often apparent that IPv6 advocates believe that IPv4 is a dead end and it will inevitably be replaced by IPv6. But that is similar to people in the eighties claiming that everything will be ISO-OSI. Did not happen either.
There is no reason to believe that 170 million addresses will be allocated each year until the available number suddenly drops to zero, at which moment the address shop closes and new applicants stand outside with no way to connect.
If you think it will work like that, just observe what happens with some other scarce resource that nears depletion.
Normally you would write that as: ::1"
"There's no place like
I'm about 10 degrees west of the center of our timezone (that in itself is funny, because timezones are supposed to be center plus or minus 7.5 degrees).
In winter, our clock time is 40 minutes ahead of solar time. In summer it is one hour and 40 minutes.
Again, it is a matter of habit. We changed to this system in world war 2 and it never changed back. Most people alive today don't have a reference to "the correct situation".
Except, when we travel and are astonished how early it gets dark.
Light conditions vs clock time really does not matter a lot. People adapt to the static offset (40 minutes in our case). The DST just adds to that.
It is typical American. When the DST rules changed here in Europe a decade ago, nobody made any fuss about it. Microsoft did not even release a fix that would handle the future rule change, one was forced to apply a patch at the correct time. Linux of course was not affected, it already had a reasonable TZ library back then.
Most people with such firm opinions/statements about the time of sunset do not realise that this whole thing is very much dependent on your latitude.
When you live at 30deg north the situation is completely different from here (at 52deg north), which is again very different from 65deg north.
Here, it is very normal to drive both to and from work in darkness in winter. But, in summer it never gets (astronomically) dark the entire night. We are completely used to that. You would be too, if you lived in such a location.
Timezone borders are not simple lines (meridians) but follow local state borders. So there is no simple formula to convert position to timezone.
An NTP server (or client) does not know its position so it cannot do this easily. It could be done in a GPS receiver server like gpsd.
However, for a practical implementation that does not cause more problems than it solves, it would have to contact an external server on Internet to perform the actual lookup.
It *is* how Microsoft did it, however they goofed at writing the conversion routines and made them much more primitive than posix timezone handling like in Linux.
That is what you are paying for now.
That is the idea of building blocks. You know what external effect they have, but the internal workings are more complex and not necessarily one requires knowledge of the internal workings to use the building block.
When I was a kid, those kits had only about 20 projects in the box and it contained transistors, resistors, capacitors, etc.
You would build a blinking light, a morse code tone generator, stuff like that. The most complex kit would build an AM radio.
With opamps and digital ICs you can build more different and more complex things, but this means you understand less of the basic workings.
An op-amp should only be looked at as a differential amplifier, and a NAND gate has some logic function, but how it is internally constructed out of transistors and resistors is less of a topic.
Ok, that confirms that Microsoft only implemented that "Dynamic DST" thing once it affected their own home country.
The KB article describes an entry for Israel that clearly needed dynamic DST at least since 2004, but on a Windows XP SP2 system patched with all critical and many non-critical hotfixes not including the DST fix there is no sign of Dynamic DST records.
The similar functionality in Linux already worked when the DST changed here back in 1996. And I think it was in place when I first installed Linux in december 1992.
(I worked with Unix systems before that, and they had either US-hardwired DST or a configurable DST similar to Windows, with only one-year scope)
One difference between a zoneinfo system and some other systems is that you can update the zoneinfo file long before the actual change.
There is no need to patch it in the months before the change, it can be done years before (assuming the upcoming change has been decided).
So, you can patch your system in february 2006 for a DST change that will take effect in march 2007. The system will probably be rebooted after the patch and before it becomes critical. You only need a reboot just before the DST date, on the systems that were not rebooted after you patched.
Has this been fixed with the release of Windows XP, or is this a new fix now that the problem affects the US?o l\TimeZoneInformation on an XP system I still don't see any.
We have had several timezone rule changes in Europe, and Windows has never kept history here.
And looking in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contr
Early Unix systems had fixed DST changeover, which was later (System V) changed to a configurable method similar to Windows.
However, open source systems have used a "zoneinfo" system for at least 15 years now. I think commercial Unix systems have switched as well.
Zoneinfo has a database of DST changeover moments in history, even (far) further back than its own creation. So UTC timestamps can be translated to local time for a wide range of dates, not only this year or even this half-year.
When the DST rules changed in Europe in 1996 I had no problems on my Linux system. Windows95 had to be patched, even though this change was known when it was released the year before. But the release was during DST so the patch could not yet be applied then, it had to wait until winter.
The Linux zoneinfo files already had the new rule for quite some time, so no need to patch.
During our Y2K preparation a standard test was used on PC systems. Some Compaq systems failed and had to be replaced by decree.
However, they worked fine for many years after. The only thing that failed was the changeover from 1999-12-31 23:59:59 to 2000-01-01 00:00:00 but that was no problem as the loginscript set the clock anyway.
But management only looked at the outcome of some "authorative" test that said FAIL.
The reason that nothing catastrophic happened was not only that everyone was well prepared, but also that the probability of a catastrophe was so much over-estimated.
(similar to what is written into the abstract at the top of this article)
When nothing had been done about Y2K, surely there might have been some problems. But I don't think that we would have found all planes falling out of the sky, all electricity plants failing, all articles in stores evaporating as if by magic (because their sell-by date was wrong), etc.
Computer "experts" like to think that computers entirely rule the world and there is no human decision factor left. But that just isn't realistic. Even when all articles in the store are past their sell-by date, it is unlikely that the store personnel will discard everything just because of that.
And when the computer says "8 o'clock" while the consumer's watch says "9 o'clock" there similarly is little chance of the world coming to an end.
When you are so careful about file timestamps, you should know that Windows does not translate them correctly anyway.
Windows has no knowledge about timezone history. It translates the UTC time to local time using its current time-offset, which depends on the current DST status only.
So, when you now look at a file timestamp (in the GUI) that you created last summer, you will find that its time is one hour off.
Even when Microsoft would finally fix this (they consider it a feature rather than a bug), they would probably not fix the historic aspect.
I.e. now that the beginning of DST shifts one month, and you would look at a file created last year in that one month window, it would probably still be off.
Timezone handling in Windows just sucks. It does not have to be that bad, it works fine in Linux (including historic changes). Microsoft just has decided to make a bad implementation and then never fix it, in the name of backward compatability.