Well I would use timestamptz, using user's timezone only to convert for display. Use cases for timestamp are very limited.
Just make sure you include a timezone info in string representations in your SQL queries. For example '2000-01-01T00:00:00Z' where Z stands for UTC. Otherwise that would insert a timestamp into a timestamptz column, in which case postgres uses local timezone setting for conversion, implicitly; this is not what you want.
Also you should use an equivalent type in you app, i.e. python datetime with tzinfo or JS Date. And beware of UTC offsets: they can't handle DST. Python pytz and JS moment-timezone provide DST-aware timezone info (which is built-in in postgres).
Edit: if you can rely on your users system time for display that's even better because you wouldn't have to explicitly deal with those DST-aware timezone info.
> Also any sane person would never sort random values.
I think sorting by a arbitrary, unique value as the last sorting dimension is useful to ensure you always get the same ordering when first dimensions are equal. For instance sorting users by (last_name, first_name, user_id) ensures homonymous users don't move around in the list from request to request.
This is quite a sane thing to do, don't you think?
> Postgres has two types of timestamps. It has a generic timestamp and one with timezone embedded in it.
That's not correct, timestamptz doesn't have a timezone embedded in it. It's just that it's timezone-aware. A timestamptz corresponds to a universal point in time that have many human reprensentations, one for each timezone. psql uses the default timezone of the postgres instance to convert a timestamptz to a displayable string, so timestamptz are always displayed with a timezone, but that info does not come from the stored value.
Timestamptz needs timezone information only for operations that would give different results in different timezones, e.g. display as string, extract the day part, add a 1-month interval (DST info needed), etc. Comparing two timestamptz however doesn't require any timezone info.
The difference between timestamp and timestamptz is not about what they store, but about how they behave.
Edit: In my experience, this is not always obvious because postgres uses the default timezone of the instance whenever it needs such info with timestamptz operations. Using an explicit timezone often requires convoluted code.
> There’s a misconception that restarting the (HTTP) request will fix the problem. That is not the case. Again, TCP will resend those packets that need resending on its own.
But that's not true if the connection is interrupted at the socket level, right?
For example, if the device switches from 3G to Wi-Fi, or from Wi-Fi to wire, then I believe, its hardware address changes, its IP address changes and the socket becomes stale. But the TCP connection, would it be closed right away or would it hang until some timeout? (And does it depend on the OS?)
I think it is because of the Blogger's "Dynamic Views" template your blog uses. Maybe another (more classic) template would be better for cross-device compatibility.
You're right. I know that CSS needs to be applied to a document; without a document there's nothing to be styled.
Still, to me saying that something is in "pure" CSS would imply that the HTML is not more complicated than e.g.:
<div id=homer></div>
(I guess that making a drawing such as the ones in the OP using only one div would not be possible until browsers accept pseudo-elements to be defined on top of other pseudo-elements.)
I understand that by "pure" the author meant "without using images". But IMHO using dozens of empty div elements isn't "pure" CSS.
How to measure a project's progress? If time is your metric, then the last 20% should be done in 20% of the total time. (And that's right, when the OP says she was 80% done, she actually was 50% done.)
If your metric is something else, what could it be? And perhaps it is not the best metric after all: a loading progress bar that goes quickly to 80% and then slows down (by a factor of 4) until the end may not be the best progress bar after all.
I guess that the difficulty is to get a precise idea of the time you need to finish something.