also automatic traders will have serves in japan if they're trading in japan so this(new cabling) isn't really going to matter at all to them
The traders it matters to are those engaging in arbitrage.
Many things (stocks, commodities, derivitives whatever) are traded on more than one market. Each market develops a price for the thing. Prices in the different markets are held reasonablly close by people engaging in arbitrage (buying in one market and selling in another). The lower you latency you have to BOTH markets the lower the risk that prices will shift to an unfavorable position while you are in the middle of executing your arbitrage.
Is a european warranty really of much value to an american? would you really want to ship your phone back to europe for warranty service and then arrange with someone in europe to receive it and ship it back to you?
Also note that drive bays were named after the size of the disks that went in the drives that went in the bays. Not after the size of the bays themselves.
Computers tend to measure things with fixed size binary numbers since these are by far the most efficient format for them to handle and process. When chosing the size of these numbers there is always a compromise between efficiency and future proofing. Usually the margin left by the designers is enough to last a while.
However for long lived standards as the years pass that margin is eaten up. Eventually it reaches the point where all the margin is eaten up and things have to be redesigned . The most recent one we hit was that the conventional MBR partition table has a limit of 2^32 sectors (=2TiB assuming standard size sectors). Making things worse is the fact that MS refuses to support the combination of a GPT partition table on the boot drive with conventional BIOS booting so the motherboard may be able to see and access the large drive but it if doesn't support UEFI you can't use the whole drive as a windows boot drive.
Afaict the next barrier we will hit is the LBA48 limit of 2^48 sectors (=128PiB assuming standard size sectors). So a 60TB drive shouldn't be any more problematic than a 3TB one.
One thing to consider is that US prices are usually quoted exclusive of sales tax while EU prices (on consumer orientated sites) are usually quoted inclusive of VAT. In my experiance this usually accounts for some but not all of the price difference between EU and US headline prices.
It would never be infinite, as TCP also has timeouts.
Your right it won't be infinite but TCP's timeouts are vey long (to cope with networks that have intrinsically high latencies such as more than one sattelite hop) and are adjusted dynamically to try and maximise throughput in the face of high network latency.
So as the buffer fills the latency will increase and the timeouts will increase with it.Eventually a window size limit or sanity check limit on the timeouts will be hit but not before the buffer contains a heck of a lot of data.
If you have a time sensitive application that needs to be run over a packet switched network, other transport protocols like UDP make a lot more sense.
The reality is different applications have to share the same network. If TCP is keeping a several seconds long FIFO full then any other traffic flowing through that FIFO will also be delayed.
Of course the real soloution is QOS. Let the latency sensitive traffic go first regardless of how long a queue the bulk traffic has built up. The trouble is it's difficult to implement in a fair manner (if the user or application developer does the marking what stops a user or application developer marking everything as high priority? If the ISP does the marking what stops them favoring their own services?) on an open network like the internet.
The price on the professional machines is usually a bit higher but you usually get less crapware loaded by default (though this doesn't really matter for this kind of customer since they will blow away the OEM install anyway and replace it with their own image), a case designed for speed of servicing (though on the flipside they are usually more propietry) and availability of "image compatible" machines for a longer period so you don't have to update your images so often.
alert attendees for the affected meeting that the time has changed; their client stores the new UTC time, and continues to display it correctly for their local time
It's not quite as simpel as alerting all attendees for the "affected meeting". You want to alert atendees for which the time has changed from their perspective. If the rules for an atendee's timezone change then a meetings time can change from their perspective without the UTC time of the meeting changing. Likewise if the rules change in the same way for the atendee's timezone and the meeting's timezone the meeting may not move from the atendees perspective even though it moved in UTC time.
But yeah generally I agree there is nothing wrong with keeping UTC times of future events in the DB for comparison purposes. The problems come when you treat them as the primary data item rather than as a generated data item whose value may change when a rule change comes through.
The alternative vote refurendum in the UK. The number of people I heard saying they'd vote no for completely false reasons was ridiculous. Fine, if you don't agree. Just make sure you know the facts first.
Sadly I think the yes campaign spectacually failed to explain what AV was and why it was a good thing (it allows people to vote for who they really want without fear that they are "throwing thier vote away" by not voting for the lesser of two evils). I only understood how AV worked after reading the stuff from the no campaign!
They also crucially provide center taps to provide a path for DC currents from the transmitter to ground and to give the receive signal the correct common mode level. Also because of the aforementioned center taps the pinouts of a jack with integrated magnetics will almost certainly differer from a plain jack.
And finally also to remove DC components, many PHYs have a constant DC component on their output lines because it's easier to vary the output currents while keeping it in the same direction than it is to change the direction of a current while maintaining smoothness.
Recording a signal with high fidelty is NOT a matter of just taking samples at defined intervals. If you do that you will get aliasing (higher frequencies getting converted to lower frequencies by the sampling process). So before you sample you need an "anti-aliasing filter" to remove signal components above the nyquist point.
However filter design is a compromise, a filter with a steep response in the frequency domain will have a long impulse response in the time domain. A filter that doesn't cause phase distortion will cause pre-echo when fed with an impulse signal. Further making high order analog filters reliable and well behaved is difficult.
Similarlly at output many digital to analog conversion methods will produce unwanted copies of the signal beyond the nyquist point, again a filter (known as a reconstrution filter) is needed to remove these.
96KHz gives you a much bigger "gaurd band" between the audio signal and the nyquist frequency so your anti-aliasing and reconstruction filters can be much less aggressive.
Using oversampling (running your recording/playback devices at higher than the sample rate you are storing the music at) and doing most of the filtereing digitally can remove the issues with high order analog filters being unstable but it can't change the fundamental issue that a filter with a sharp response in the frequency domain will have a long impulse response in the time domain or that a filter with no phase distortion in the frequency domain will have pre-echo in the time domain.
Cellphone contracts in Canada are criminal. All of them state: "no guarantee of service". i.e. Give us your money and we may or may not give you something for it. No other business is allowed to get away with this. I am constantly amazed that people sign these agreements. I guess the desire to look cool overwhelms all reason.
No the desire to keep in contact when on the move overwhelms the dislike of the one-sided contract terms.
Cellphone service is always going to be "no gaurantee" because there are just too many things beyond the network's reasonable control that could stop you getting service be it too many people converging in a small area or buildings screwing up the radio propagation.
BTW here in europe we have our own issues with cellphone prices. Europe is divided into countries comparable in size to US states but as soon as you cross the border your cellphone prices go through the roof.
I'd think caps as low as 3GB per month are going to be discouraging video streaming as well as bulk downloading.
That asside while bulk downloading may be more evenly spread it can also be massively higher in volume, should a user who is maxing out their connection most of the time and wose is doing so with agressive protocols like bittorrent really pay the same as someone who is just browsing the web and checking email?
"he was like ssl, yeah I haven't throught about that in a long time. and he was like amazing..... Oh these certificate authorities whats the deal with them...oh that whole authenticity thing yeah we just threw that in at the end...he was like ssl yeah I mean we were really designing it to prevent passive attacks, the whole man in the middle thing someone told us about that and you know we just kind of threw that thing in at the end, really that whole certificate authority thing it was a bit of a hand wave
So it sounds like they did put CAs in as an attempt to defend against MITM attacks but they didn't really care too much about whether it worked or not.
Which makes far more sense than the GGPs claim that the system was not designed to stop MITM attacks at all. If you aren't trying to defend against MITM attacks at all then there really isn't any point in having CAs in the first place.
Plus the CA system has got weaker over the years, when it was first introduced you had to convince one of a couple of companies that you were either the legitimate owner of the domain or that you are not the legitimate owner of the domain but they should give you the cert anyway. Now you have to convince one of the CAs listed in http://www.mozilla.org/projects/security/certs/included/ or one of the many sub-cas they delegate to that you are either the legitimate owner of the domain or that you are not the legitimate owner of the domain but they should give you the cert anyway.
IIRC it still doesn't provide a secure random number generator as part of the core language. Given it's target application often requires generating things like session IDs that if guessed can allow session hijacking that seems pretty inexcusable to me.
Read it but remember it's a whitepaper, that is it's the companies claims about it's own products, NOT a third party opinion of the product. It is also completely lacking in hard comparisons to other devices with comparable sensor size but more conventional pixel counts.
One major question is what does having lots of small pixels (more than the lens can likely resolve) and averaging them gain you over having fewer larger pixels (which gather more light per pixel and hence have less noise). The main answer seems to be that you can output in any resoloution without having to scale down by small factors or worse scale-up.
The other question is does the bigger sensor and better optics you can get into a limited sized device by not having optical zoom make up for the fundamental disadvantage of digital zoom (which is that you are only using part of your sensor area).
P.S. someone else categorised this as a camera with a phone built in rather than a phone with a camera built in and i'm inclined to agree with them.
However both PC serial ports and early moderms DID use one bit per symbol so bitrate and baudrate were the same. Later modems did move to multiple bits per symbol but the connections to the host computers were still one bit per symbol and afaict users continued to use the terms bitrate and baudrate synonymously.
No, in the 1980s, desktop computers took about 1 second to boot up: Click, beep! and you are going
Into the rom based basic interpreter.
then you had to load your application software. If you were very lucky you might have that in rom too. If you were moderately lucky/rich you loaded it off a floppy disc, if you were unlucky/poor you loaded it off audio casette. Oh and if you wanted to switch programs you had to load it again. So if you were writing a document and wanted to check your email or look up some information you would have to save your work, reboot the system, load your terminal program, dial up the remote system, log in, do your stuff, reboot the system again and reload your word processor. No thanks.
A dedicated terminal would avoid this but it would of course also mean paying a lot of money for an essentially single purpose device.
Yes modern PCs may take longer to boot but the total time to boot and load an application is almost certainly shorter and you can keep things running in the background.
The problem especially for liability insurance is systemic risks such as the risk of a commonly used material being found to cause cancer DECADES after exposure or the risk of a change in compensation attitudes by a major countries court system. Systemic risks unlike random risks don't dilute much as you make the pool of customers bigger.
Using UTC for everything is NOT a soloution because you cannot reliablly convert a future time between local time and UTC (the conversion rules could change at any time) and since the real world runs on local time you need to be able to schedule events at a future local time.
The proper soloution is to store both the time of an event and the timezone that event is defined in. Then when a new set of rules come along you have to process the new rules and generate a set of warnings about any new conflicts introduced and any events that have moved relative to each users local time.
You seem to have misunderstood the point the GP was making.
No he hasn't misunderstood it at all.
Those problems only become issues for people working with heterogeneous data sets
No they also become a problem for any system that deals with future events scheduled by people. Like it or not the real world schedules things on local time and like it or not it is not possible to reliablly convert future times between local time and universal time because the mapping rules can be changed at any time. Sometimes with very little notice.
Consider a user sets a repeating alarm for 7AM local time on every weekday. That user damn well expects an alarm at 7AM local time even if the mapping between local time and universal time has changed in the meantime (either due to a DST jump or a rule change).
Consider a user schedules a meeting for 9AM local time on a given day. The users damn well expect that meeting to stay scheulded for 9AM local time even if the mapping rules change between the meeting being scheduled and the meeting happening.
Things get even worse if you have users from different timezones. Now you have to store which local time an event is scheduled in. Then when an update to the timezone rules come in you have to
1: find any users who are associated with events in foreign timezones. 2: Recompute the translation from the event's local time to the user's local time. 3: See if that translation has changed, if so generate a warning for the user and re-run any conflict checking that your system does.
Oh and you can't rely on end users computers to reliablly convert between universal time and a given timezone even for times in the past firstly because they may not be up to date and secondly because windows doesn't keep data on historical mapping rules.
This is tricky to get right and the results of getting it wrong only tend to show up occasionally especially for users in the west (whose governments seem to have some understanding of the value of stable timezone rules) so a great many systems get it wrong causing all sorts of fun when a rule change comes in.
Now suppose that traffic lights are supposed to use different rules in rush hour which is defined in terms of working hours which in turn are defined in terms of local time. Add that to the fact that it is not possible to reliablly convert future times between universal time and local time and you might understand why time issues are so easy to fuck up. Using entirely local time is not a soloution and neither is using entirely universal time. Any app that works with time and wants things to work properly in line with user expectation has to understand timezones and DST.
1: At the nyquist limit you won't get amplitude (or even nessacerally see the signal at all depending on the phase relationship between the signal and your sampling clock) 2: At any frequency below the nyquist limit you can IN theory recover the amplitude but the closer you get to the nyquist frequency the closer your anti-aliasing and reconstruction filters need to be to perfect and this causes problems of it's own (transform a perfect filter from the frequency domain to the time domain and you will find it is non-causal and has an infinitely long impulse response).
Slashdot Mirror
also automatic traders will have serves in japan if they're trading in japan so this(new cabling) isn't really going to matter at all to them
The traders it matters to are those engaging in arbitrage.
Many things (stocks, commodities, derivitives whatever) are traded on more than one market. Each market develops a price for the thing. Prices in the different markets are held reasonablly close by people engaging in arbitrage (buying in one market and selling in another). The lower you latency you have to BOTH markets the lower the risk that prices will shift to an unfavorable position while you are in the middle of executing your arbitrage.
Is a european warranty really of much value to an american? would you really want to ship your phone back to europe for warranty service and then arrange with someone in europe to receive it and ship it back to you?
but do you ask for a 8.89 or 6.35 cm harddrive?
Also note that drive bays were named after the size of the disks that went in the drives that went in the bays. Not after the size of the bays themselves.
Computers tend to measure things with fixed size binary numbers since these are by far the most efficient format for them to handle and process. When chosing the size of these numbers there is always a compromise between efficiency and future proofing. Usually the margin left by the designers is enough to last a while.
However for long lived standards as the years pass that margin is eaten up. Eventually it reaches the point where all the margin is eaten up and things have to be redesigned . The most recent one we hit was that the conventional MBR partition table has a limit of 2^32 sectors (=2TiB assuming standard size sectors). Making things worse is the fact that MS refuses to support the combination of a GPT partition table on the boot drive with conventional BIOS booting so the motherboard may be able to see and access the large drive but it if doesn't support UEFI you can't use the whole drive as a windows boot drive.
Afaict the next barrier we will hit is the LBA48 limit of 2^48 sectors (=128PiB assuming standard size sectors). So a 60TB drive shouldn't be any more problematic than a 3TB one.
One thing to consider is that US prices are usually quoted exclusive of sales tax while EU prices (on consumer orientated sites) are usually quoted inclusive of VAT. In my experiance this usually accounts for some but not all of the price difference between EU and US headline prices.
It would never be infinite, as TCP also has timeouts.
Your right it won't be infinite but TCP's timeouts are vey long (to cope with networks that have intrinsically high latencies such as more than one sattelite hop) and are adjusted dynamically to try and maximise throughput in the face of high network latency.
So as the buffer fills the latency will increase and the timeouts will increase with it .Eventually a window size limit or sanity check limit on the timeouts will be hit but not before the buffer contains a heck of a lot of data.
If you have a time sensitive application that needs to be run over a packet switched network, other transport protocols like UDP make a lot more sense.
The reality is different applications have to share the same network. If TCP is keeping a several seconds long FIFO full then any other traffic flowing through that FIFO will also be delayed.
Of course the real soloution is QOS. Let the latency sensitive traffic go first regardless of how long a queue the bulk traffic has built up. The trouble is it's difficult to implement in a fair manner (if the user or application developer does the marking what stops a user or application developer marking everything as high priority? If the ISP does the marking what stops them favoring their own services?) on an open network like the internet.
The price on the professional machines is usually a bit higher but you usually get less crapware loaded by default (though this doesn't really matter for this kind of customer since they will blow away the OEM install anyway and replace it with their own image), a case designed for speed of servicing (though on the flipside they are usually more propietry) and availability of "image compatible" machines for a longer period so you don't have to update your images so often.
alert attendees for the affected meeting that the time has changed; their client stores the new UTC time, and continues to display it correctly for their local time
It's not quite as simpel as alerting all attendees for the "affected meeting". You want to alert atendees for which the time has changed from their perspective. If the rules for an atendee's timezone change then a meetings time can change from their perspective without the UTC time of the meeting changing. Likewise if the rules change in the same way for the atendee's timezone and the meeting's timezone the meeting may not move from the atendees perspective even though it moved in UTC time.
But yeah generally I agree there is nothing wrong with keeping UTC times of future events in the DB for comparison purposes. The problems come when you treat them as the primary data item rather than as a generated data item whose value may change when a rule change comes through.
The alternative vote refurendum in the UK. The number of people I heard saying they'd vote no for completely false reasons was ridiculous. Fine, if you don't agree. Just make sure you know the facts first.
Sadly I think the yes campaign spectacually failed to explain what AV was and why it was a good thing (it allows people to vote for who they really want without fear that they are "throwing thier vote away" by not voting for the lesser of two evils). I only understood how AV worked after reading the stuff from the no campaign!
http://www.msnbc.msn.com/id/14825048/ns/health-heart_health/t/yrs-after-transplant-heart-patient-healthy/
They also crucially provide center taps to provide a path for DC currents from the transmitter to ground and to give the receive signal the correct common mode level. Also because of the aforementioned center taps the pinouts of a jack with integrated magnetics will almost certainly differer from a plain jack.
http://www.smsc.com/media/Downloads_Public/lan9000/9512_sch.pdf
(that is a reference design for the lan chip the Pi guys are using)
So without the correct magnetics things are unlikely to work at all.
And finally also to remove DC components, many PHYs have a constant DC component on their output lines because it's easier to vary the output currents while keeping it in the same direction than it is to change the direction of a current while maintaining smoothness.
Recording a signal with high fidelty is NOT a matter of just taking samples at defined intervals. If you do that you will get aliasing (higher frequencies getting converted to lower frequencies by the sampling process). So before you sample you need an "anti-aliasing filter" to remove signal components above the nyquist point.
However filter design is a compromise, a filter with a steep response in the frequency domain will have a long impulse response in the time domain. A filter that doesn't cause phase distortion will cause pre-echo when fed with an impulse signal. Further making high order analog filters reliable and well behaved is difficult.
Similarlly at output many digital to analog conversion methods will produce unwanted copies of the signal beyond the nyquist point, again a filter (known as a reconstrution filter) is needed to remove these.
96KHz gives you a much bigger "gaurd band" between the audio signal and the nyquist frequency so your anti-aliasing and reconstruction filters can be much less aggressive.
Using oversampling (running your recording/playback devices at higher than the sample rate you are storing the music at) and doing most of the filtereing digitally can remove the issues with high order analog filters being unstable but it can't change the fundamental issue that a filter with a sharp response in the frequency domain will have a long impulse response in the time domain or that a filter with no phase distortion in the frequency domain will have pre-echo in the time domain.
Cellphone contracts in Canada are criminal. All of them state: "no guarantee of service". i.e. Give us your money and we may or may not give you something for it. No other business is allowed to get away with this. I am constantly amazed that people sign these agreements. I guess the desire to look cool overwhelms all reason.
No the desire to keep in contact when on the move overwhelms the dislike of the one-sided contract terms.
Cellphone service is always going to be "no gaurantee" because there are just too many things beyond the network's reasonable control that could stop you getting service be it too many people converging in a small area or buildings screwing up the radio propagation.
BTW here in europe we have our own issues with cellphone prices. Europe is divided into countries comparable in size to US states but as soon as you cross the border your cellphone prices go through the roof.
I'd think caps as low as 3GB per month are going to be discouraging video streaming as well as bulk downloading.
That asside while bulk downloading may be more evenly spread it can also be massively higher in volume, should a user who is maxing out their connection most of the time and wose is doing so with agressive protocols like bittorrent really pay the same as someone who is just browsing the web and checking email?
And listening a bit further
"he was like ssl, yeah I haven't throught about that in a long time. and he was like amazing ..... Oh these certificate authorities whats the deal with them...oh that whole authenticity thing yeah we just threw that in at the end...he was like ssl yeah I mean we were really designing it to prevent passive attacks, the whole man in the middle thing someone told us about that and you know we just kind of threw that thing in at the end, really that whole certificate authority thing it was a bit of a hand wave
So it sounds like they did put CAs in as an attempt to defend against MITM attacks but they didn't really care too much about whether it worked or not.
Which makes far more sense than the GGPs claim that the system was not designed to stop MITM attacks at all. If you aren't trying to defend against MITM attacks at all then there really isn't any point in having CAs in the first place.
Plus the CA system has got weaker over the years, when it was first introduced you had to convince one of a couple of companies that you were either the legitimate owner of the domain or that you are not the legitimate owner of the domain but they should give you the cert anyway. Now you have to convince one of the CAs listed in http://www.mozilla.org/projects/security/certs/included/ or one of the many sub-cas they delegate to that you are either the legitimate owner of the domain or that you are not the legitimate owner of the domain but they should give you the cert anyway.
IIRC it still doesn't provide a secure random number generator as part of the core language. Given it's target application often requires generating things like session IDs that if guessed can allow session hijacking that seems pretty inexcusable to me.
Read it but remember it's a whitepaper, that is it's the companies claims about it's own products, NOT a third party opinion of the product. It is also completely lacking in hard comparisons to other devices with comparable sensor size but more conventional pixel counts.
One major question is what does having lots of small pixels (more than the lens can likely resolve) and averaging them gain you over having fewer larger pixels (which gather more light per pixel and hence have less noise). The main answer seems to be that you can output in any resoloution without having to scale down by small factors or worse scale-up.
The other question is does the bigger sensor and better optics you can get into a limited sized device by not having optical zoom make up for the fundamental disadvantage of digital zoom (which is that you are only using part of your sensor area).
P.S. someone else categorised this as a camera with a phone built in rather than a phone with a camera built in and i'm inclined to agree with them.
Technically that is true.
However both PC serial ports and early moderms DID use one bit per symbol so bitrate and baudrate were the same. Later modems did move to multiple bits per symbol but the connections to the host computers were still one bit per symbol and afaict users continued to use the terms bitrate and baudrate synonymously.
No, in the 1980s, desktop computers took about 1 second to boot up: Click, beep! and you are going
Into the rom based basic interpreter.
then you had to load your application software. If you were very lucky you might have that in rom too. If you were moderately lucky/rich you loaded it off a floppy disc, if you were unlucky/poor you loaded it off audio casette. Oh and if you wanted to switch programs you had to load it again. So if you were writing a document and wanted to check your email or look up some information you would have to save your work, reboot the system, load your terminal program, dial up the remote system, log in, do your stuff, reboot the system again and reload your word processor. No thanks.
A dedicated terminal would avoid this but it would of course also mean paying a lot of money for an essentially single purpose device.
Yes modern PCs may take longer to boot but the total time to boot and load an application is almost certainly shorter and you can keep things running in the background.
The problem especially for liability insurance is systemic risks such as the risk of a commonly used material being found to cause cancer DECADES after exposure or the risk of a change in compensation attitudes by a major countries court system. Systemic risks unlike random risks don't dilute much as you make the pool of customers bigger.
Everything should be in UTC.
NO NO NO
Using UTC for everything is NOT a soloution because you cannot reliablly convert a future time between local time and UTC (the conversion rules could change at any time) and since the real world runs on local time you need to be able to schedule events at a future local time.
The proper soloution is to store both the time of an event and the timezone that event is defined in. Then when a new set of rules come along you have to process the new rules and generate a set of warnings about any new conflicts introduced and any events that have moved relative to each users local time.
You seem to have misunderstood the point the GP was making.
No he hasn't misunderstood it at all.
Those problems only become issues for people working with heterogeneous data sets
No they also become a problem for any system that deals with future events scheduled by people. Like it or not the real world schedules things on local time and like it or not it is not possible to reliablly convert future times between local time and universal time because the mapping rules can be changed at any time. Sometimes with very little notice.
Consider a user sets a repeating alarm for 7AM local time on every weekday. That user damn well expects an alarm at 7AM local time even if the mapping between local time and universal time has changed in the meantime (either due to a DST jump or a rule change).
Consider a user schedules a meeting for 9AM local time on a given day. The users damn well expect that meeting to stay scheulded for 9AM local time even if the mapping rules change between the meeting being scheduled and the meeting happening.
Things get even worse if you have users from different timezones. Now you have to store which local time an event is scheduled in. Then when an update to the timezone rules come in you have to
1: find any users who are associated with events in foreign timezones.
2: Recompute the translation from the event's local time to the user's local time.
3: See if that translation has changed, if so generate a warning for the user and re-run any conflict checking that your system does.
Oh and you can't rely on end users computers to reliablly convert between universal time and a given timezone even for times in the past firstly because they may not be up to date and secondly because windows doesn't keep data on historical mapping rules.
This is tricky to get right and the results of getting it wrong only tend to show up occasionally especially for users in the west (whose governments seem to have some understanding of the value of stable timezone rules) so a great many systems get it wrong causing all sorts of fun when a rule change comes in.
Now suppose that traffic lights are supposed to use different rules in rush hour which is defined in terms of working hours which in turn are defined in terms of local time. Add that to the fact that it is not possible to reliablly convert future times between universal time and local time and you might understand why time issues are so easy to fuck up. Using entirely local time is not a soloution and neither is using entirely universal time. Any app that works with time and wants things to work properly in line with user expectation has to understand timezones and DST.
To clear up some misconceptions here
1: At the nyquist limit you won't get amplitude (or even nessacerally see the signal at all depending on the phase relationship between the signal and your sampling clock)
2: At any frequency below the nyquist limit you can IN theory recover the amplitude but the closer you get to the nyquist frequency the closer your anti-aliasing and reconstruction filters need to be to perfect and this causes problems of it's own (transform a perfect filter from the frequency domain to the time domain and you will find it is non-causal and has an infinitely long impulse response).