The mess that is Photos on iOS and OSX

In article , Sandman
wrote:

see other post for more details.

Other post contained no details, and had some serious misconceptions about
cloudkit in it.

it contained sufficient details to make my point and nothing about it
was a misconception.

Try again?

what for? you're wrong and still wrong.

In article , Sandman
wrote:

Nothing to do with my news server. The time stamp is applied at
your end.

it's not at my end.

both messages were posted within a fraction of a second of each
other.

Your news client sets the date, and apparently it set the date to the time
of writing it, not the time of pushing it to the server. So three minutes
apart is the time it took you to write the first and start the second.

interesting theory, but it's completely wrong.

even though i know you're full of ****, i tested it anyway. i made
several posts to other threads, written several over an hour apart.

the time stamps showed the time the post was actually posted to the
newsserver, not the time the post was begun or completed at my end.

after posting the batch, all of the posts were at the most, within a
couple of seconds of each other, confirmed on two different servers.

as i said, the problem is not at my end.

not that the time stamps have *any* relevance to the topic. it's
nothing more than another ridiculous diversion from eric.

In article , nospam wrote:

nospam:
maybe you are, but 'we' are not.

Sandman:
The transition is the same for everyone. Whether or
not it is a problem is another question. But the transition is
underway and it applies to everyone.

nospam:
the transition is not the same for everyone.

Sandman:
Yes, it is.

nope. not in the least.

Yes, it is.

for some people the transition will be a huge pain in the ass and
for others there will be absolutely no hassle whatsoever. most
people fall in the middle somewhere.

Whether or not it will be a hassle or problem for anyone hasn't been
mentioned by me. I am stating the current state of the transition, and it
applies to everyone. No one can use iCloud Photos on the Mac, and no one
can use iCloud Photos on iOS without removing the iTunes-synced photos. The
transition applies equallly to everyone. Whether or not it's a problem or
how much you are affected by it is a totally seperate question which I
haven't talked about.

nospam:
some people will continue to use aperture until the very end
when it stops working. apple has guaranteed it will work through
yosemite which just came out, so those people have several years
of life left as long as they keep using yosemite and it might
even work with whatever comes after but no guarantees there.

Sandman:
This has nothing to do with the transition I am in reference to.

yes it most certainly does.

Incorrect.

nospam:
lightroom now supports directly importing aperture libraries,
making it easier than it was several months ago.

Sandman:
Indeed. Not that it was all that hard before.

it's a lot more straightforward than it was before since it's now a
feature in lightroom, whereas before it was a manual process.

It was a three-step manual process. I don't know how the built in process
works so I can't compare.

nospam:
so no, the transition is without question, not the same for
everyone. not even close to similar, let alone the same.

Sandman:
It's identical. Whether or not it is a problem for many or most,
or whether or not they are affected by it is another question all
together.

then it's not identical.

It is. If you change the speed limit of a road from 55 to 70, it's equal to
everyone driving on that road, whether or not you drive your car at that
speed or not. You can drive on that road at 45 before and after the
transition and you will not be affected by the transition/change, but it is
equal to you as anyone else.

identical means the same. if it varies for different people, then it
cannot be identical.

"Identical" is one word, the question is *what* is identical, not just
"identical". Since the correct initial claim is:

"The transition is the same for everyone"

One can note that it doesn't say that the transition *affects* everyone the
same, but it applies equally to everyone. I.e. you're nitpicking.

nospam:
not only that and as i've said it before, making any decision
now is premature. the wisest thing to do is wait until photos
ships and see whether it fits one's needs and at *that* point,
decide what to do.

Sandman:
Which is exactly what I am doing.

if you've switched to lightroom already, you've made your decision.

As I've said, I'm using both.

doing so at this point is not a good idea.

How do you know? What little we know of Photos for OSX isn't very
promising.

what you've described is using both, which means you haven't made a
decision.

Not have I claimed to have made a descision either.

Sandman:
And anyone doing this would be affected by this transition as
outlined in the video.

nope. those who switched to lightroom will be unaffected by apple's
cloud offerings, no matter how good or bad they might turn out to
be.

The "this" in the above sentence is in reference to your "the wisest thing
to do is wait until photos ships". Keep up!

nospam:
adobe knows that so they're desperately trying to grab as many
users as they can *before* photos comes out, because once those
users switch to lightroom they won't switch back to photos.

Sandman:
Sure they could. I am currently using both Lightroom and Aperture
from the same base photos, so if Photos turns out to be great,
switching to it would be as easy as if I had never used Lightroom.

they 'could' but they won't.

I'm waiting for a reason for this.

it's a hassle to switch once and an even bigger hassle to switch
back, plus the conversion is a lossy process so doing it twice is a
really stupid thing to do.

WTF? I am *currently* using *both* Aperture/iPhoto *and* Lightroom for the
same photos. I have the full power of all three applications available for
all my photos. When Photos is released and if it's awesome, switching to it
from my Aperture/iPhoto library will be as easy had I never even installed
Lightroom.

if you're still using aperture, you haven't switched and you're
playing both sides of the fence. you're keeping two separate
databases maintained with two different raw processing engines.

I've never claimed that I've switched. I am using both Aperture and
Lightroom and have their respective databases using the same photos.

not only is that totally insane and just asking for problems, but
you're probably the only person to do that.

What? In what way, prey tell, is that insane? They are completely seperate
and since neither ever touches the original files, it's totally safe.

those who have switched from aperture to lightroom have abandoned
aperture. switching *back* is not on their radar.

No one need to "switch" anything. Both are applications that have an
internal database that point to files on the HD. Both can also manage those
files internally, but you can elect to have the photos untouched on the HD.
*everything* in Aperture is inside the Aperture library, except the
original photos - same with Lightroom.

adobe knows this and is desperately trying to get people to switch
to lightroom before that window of opportunity closes.

Not sure how this supposed "desperation" is manifasting itself. All I've
seen is them posting about an upcoming migration tool for Aperture users
when Aperture was EOL:ed, and then releasing it. That's a nice service for
stranded Aperture users (or rather, those that feel stranded), and hardly
"desperate".

Sandman:
Now we have a new service called "iCloud Photos", still in
beta. If you enable it on your iOS device, it will remove
all synced photos from iTunes since for unknown reasons
these cannot co-exist.

nospam:
the reasons are known and well understood by those
who aren't trolling.

Sandman:
Cool, so can you explain it then? What kind of first
hand access do you have to iOS development? Why does iOS need
to delete iTunes-synced content in order to use iCloud Beta.
Don't be afraid to be technical.

nospam:
i have full access to ios/osx development information since i'm
a developer

Sandman:
As am I, I've missed the information available to developers that
outlined the reasons why iOS Photos has to delete iTunes-synced
photos in order to use iCloud Photos.

then you aren't paying attention.

I am.

nospam:
but that's irrelevant since the issue has been publicly
discussed on numerous venues. there's nothing secret about it
whatsoever. the issues are well known and well understood.

Sandman:
You just can't point to, or repeat those supposed reasons here.

i did, twice.

You failed, twice.

nospam:
nevertheless, for those that live in a cave, apple is switching
to cloudkit, which is entirely new and incompatible with what
came before. you get one or the other.

Sandman:
This is of course false. iOS Photos has the ability to see albums
synced from iTunes and albums synced from iCloud Photos. "You get
one or the other" isn't a reason, it's an empty claim.

nothing about it is false.
http://www.imore.com/troubleshoot-ic...c-images-from-
iphoto

Everything about it is false. The link above explains the current state of
affairs, just like I did in my OP. But, it doesn't give any reason as to
*WHY*, which is exactly what I said. The link above agrees with everything
I said.

nospam:
what came before, core data and icloud, was fundamentally
broken. apple fixed a lot of the issues but realized it could
never work properly so they said **** it and started over.

the two are not compatible. in other words, it's either/or.

Sandman:
So in other words - you have no idea, just as I thought. We all
know that iOS Photos has the ability to use both Core Data and
Cloudkit, what we *don't* know is why it can't access both at the
same time.

it's not me who has no idea.

It is.

Sandman:
To be clear - iOS Photos does *not* use Core Data + iCloud, it
does NOT sync your Core Data to iCloud. iCloud Photostream is a
seperate function on top of Core Data.

you clearly don't understand what you're talking about.

I clearly do.

first of all, this isn't about ios photos, it's about mac photos,
which is not available yet.

No, this is about iOS Photos, since that's what the OP was about. You're
just confused.

second, it's about the new cloudkit.

No, it isn't. It may be what you THINK it is about, but it isn't. CloudKit
is an API to transfer data from the cloud, that's all.

third, an app can continue to use the old coredata/icloud model if
it wants, but it's incompatible with using cloudkit.

iOS Photos does *NOT* use Core Data + iCloud, so this is an irrelevant
point.

Enabling iCloud for Core Data stores *everything* in Core Data in iCloud.

it could potentially use both but that would be a lot of work and a
complete waste of time for developers.

No one is suggesting they use both, since they don't use Core Data + iCloud
today.

iOS Photos today use Core Data to store photos in the file system. For the
sake of argument, let's claim they store them based on their albums in the
app (it probably doesn't, but bear with me). So you have:

Photos/Camera Roll Local content
Photos/Funny iOS-created album
Photos/Photo Stream Sync via iCloud
Photos/Shared/Family Sync via iCloud
Photos/USA 2014 Synced from iTunes

That's 100% Core Data, then using iCloud syncing for one or a few albums,
which is a function of the app, much like how any app can sync content from
the internet to Core Data (i.e. Dropbox etc).

Now, enable iCloud Photos, and all of the above is removed and replaced
with a album structured from the cloud, but there is no *need* for it to
be. There is no obvious reason why Apple won't allow for this:

Photos/Camera Roll iCloud Photos synced
Photos/Funny iCloud Photos synced
Photos/Photo Stream iCloud Photos synced
Photos/Shared/Family iCloud Photos synced
Photos/USA 2014 Synced from iTunes

Since iOS Photos already has the ability to on a per-album level decide
whether its content should be synced or not, it's not obvious why that "USA
2014" album needs to be removed for the other functionality to be enabled.

*That's* the question you need to answer, and have failed to do.

Sandman:
Cloudkit does NOT store data on your device, it's a transfer
protocol using API's to read data from the Cloud. Cloudkit doesn't
sync anything, you would still use Core Data to store local copies
of photos.

so what? that doesn't change anything i said.

It does, since any developer can use CloudKit *and* Core Data + iCloud.
They are not exclusive funcitonalities and it's not "one or the other".

Sandman:
As a developer, it would be easy to mark folders as synced by
iCloud photos and those synced by iTunes and only enable iCloud
Photos for particular folders/albums. The only concievable reason
for Apple not allowing for this is because they feel it would be
confusing for the end user to have non-syncing and syncing photos
on their iOS devices, which I think is a *bad* reason.

There is no *technical* reason for Apple to not allow for both,
and your allusions to Core Data and Cloudkit being seperate and
exclusive is patently false.

they do allow for both, but developers are going to pick cloudkit,
especially the ones who have been burned by core data and icloud.

Which is *irrelevant* since iOS Photos *does not use* Core Data with iCloud
syncing.

there are also a lot of technical reasons why core data and icloud
will never work properly, which is why mainly why cloudkit was
developed in the first place.

Agreed, but that has nothing to do with the current question, or even iOS
Photos.

nospam:
weren't you switching to lightroom anyway?

Sandman:
I'm using both.

nospam:
that's an incredibly bad idea.

Sandman:
No it's not.

it's a very bad idea since you're using two incompatible asset
management apps with two totally different raw processing engines,
one of which has been eol-ed.

Which in itself is not a bad idea at all. The original photos are untouched
by either application, as you should know.

there is no point to that.

There is a point if one wants to use LR for their entire photo library
(80k+ photos) and get comfortable with it during this transitional period
before he or she knows whether or not they will switch or not.

Sandman:
For this reason, I have not yet turned on iCloud
Photos, which means that iPhoto/Aperture, my iPhone and my
iPad all sync their photos via the "My Photo Stream" album
on each device, which means that edits are not syned
either, since the old Photo Stream doesn't support it.

It's a feature vaccum, currently, were the end user is
left waiting for other pieces of the puzzle to be released
for it to actually work as advertised.

nospam:
why don't you call apple and help them finish it
sooner.

Sandman:
Because I can't help them finish it sooner.

nospam:
then stop whining.

Sandman:
I'm not whining, I am pointing out the current status of photos on
iOS and OSX.

photos on ios is not the issue and has little to do with photos on
the mac other than the name.

Sigh. Photos on iOS *IS* the issue. Here is the video again and see the
issue first hand:

https://www.youtube.com/watch?v=vSyBkDF7pJc

That's the current mess you're stuck with unless you turn on iCloud Photos,
which you *CAN NOT DO* if you wish to have photos from your Mac (or PC) on
your iOS device.

there will be some overlap in features but what ultimately gets released
on the mac will do a lot more.

Nothing in this thread has been about the feature-set of Photos for OSX.

photos on mac is not done. go call apple and help them finish it and
have it work the way you want it to work if you think you know
better.

I would be more interested in fixing iOS Photos to work neatly during this
transitional period.

not only that, but photos on ios is likely to be revised to work
with photos on mac.

Maybe, but it would be better to be revised to work nicely during the
period up until Photos for the Mac is released.

nospam:
photos will be done when it's done, but probably released before
it's truly done.

Sandman:
And probably will be less than iPhoto functionality-wise.

another completely bogus assumption.

Assumption, yes. Bogus no. Based on what we know. You may not have the same
assumption, which is fine, but that's my assumption and I have posted many
times about why this is a perfectly valid assumption.

Here's a couple of comparisons I've made befo

http://sandman.net/files/photos_vs_iphoto.jpg

That's Photos compared to the controls in iPhoto, which seems to overlap
nicely, but illustrates also that what little we know of Photos is that
it's more or less should-to-shoulder with iPhoto when it comes to image
processing, which isn't saying much.

That's ignoring things like keywords, smart albums, faces, effects, social
services syncing and quick fixes in iPhoto, not to mention ordering prints,
calendars, making slideshows etc etc.

Here is a comparison to Preview:

http://sandman.net/files/photos_vs_preview.jpg

It's a bit funny that even a low-end tool like the built in image
processing tools of OSX is a pretty good match of what we know about
Photos. Granted, I am assuming that Photos will do a better job with many
of these settings than Preview.

And finally, here's a comparison to Apertu

http://sandman.net/files/photos_vs_aperture.jpg

Yeah, I know, not a pretty good comparison. As far as we know, Photos
doesn't even have noise reduction.

photos will likely be something in between iphoto and aperture,
eventually growing to do nearly all of what aperture did.

That is indeed a bogus assumption. It isn't based on any information from
Apple at all. That's fine as far as expectations or hopes goes, and I want
to believe you're right, but there is nothing official that says that this
is even remotely going to be true.

that much is clearly obvious from what apple has already shown,
which wasn't all that much anyway.

This is false. What Apple has shown is a mere shadow of iPhoto. What you're
*hoping* for is that when released it will be a lot *more* than what Apple
has shown us. And I am right there hoping with you, I'm just not holding my
breath.

all they had last june was a canned demo that showed a couple of
features. there was no actual app at that time. however, there have been
numerous hints along the way.

None of which "hint" at your claim, of course. The closest thing you've
come is that they've said it will support plugins. That's all.

Or rather - support it! Show me these "hints" that puts Photos somewhere
between iPhoto and Aperture feature-wise.


--
Sandman[.net]

In article , nospam wrote:

In article , Sandman

nospam:
see other post for more details.

Sandman:
Other post contained no details, and had some serious
misconceptions about cloudkit in it.

it contained sufficient details to make my point and nothing about
it was a misconception.

Incorrect.

Sandman:
Try again?

what for? you're wrong and still wrong.

Incorrect.


--
Sandman[.net]

In article , nospam wrote:

In article , Sandman

Eric Stevens:
Nothing to do with my news server. The time stamp is applied
at your end.

nospam:
it's not at my end.

both messages were posted within a fraction of a second of each
other.

Sandman:
Your news client sets the date, and apparently it set the date to
the time of writing it, not the time of pushing it to the server.
So three minutes apart is the time it took you to write the first
and start the second.

interesting theory, but it's completely wrong.

That's why it's a theory.

even though i know you're full of ****

Nothing I wrote above was "****", it was all 100% true, and a theory to
explain the different timestamps.

i tested it anyway. i made several posts to other threads, written
several over an hour apart.

the time stamps showed the time the post was actually posted to the
newsserver, not the time the post was begun or completed at my end.

Curious then that the two earlier posts had time stamps three minutes
apart.

after posting the batch, all of the posts were at the most, within a
couple of seconds of each other, confirmed on two different servers.

Neat. And using those same servers, what were the timestamps of those two
earlier posts you made - those that show up three minutes apart on my (and
Eric's) server?

as i said, the problem is not at my end.

It isn't a problem at all, at anyone's end. But your posts were timestamped
three minutes apart.

not that the time stamps have *any* relevance to the topic. it's
nothing more than another ridiculous diversion from eric.

That I agree with. I was trying to give a theory to explain the disrepancy
of your timestamps, which in fact was a very valid theory.

Still waiting for more info - like the timestamps you see on the posts on
those two test servers you used above, but for those initial two posts.


--
Sandman[.net]

On Mon, 08 Dec 2014 10:33:29 -0500, nospam
wrote:

In article , Eric Stevens
wrote:


both messages were written locally and posted as a batch at the same
time, which means there was no message id when i wrote them or when
they were posted.

OK. I see that. There are three minutes separating the two messages. I
would have thought they were dated and time stamped when they were
posted, not when you put finger to key board.

your news server sucks. both messages were posted within a fraction of
a second of each other. there should not be a 3 minute delay. there
should not even be a 3 *second* delay. at the most, they should differ
by one second, if one was made slightly before the second clicked over.

Nothing to do with my news server. The time stamp is applied at your
end.

it's not at my end.

both messages were posted within a fraction of a second of each other.

From 1987 http://www.w3.org/Protocols/rfc850/rfc850.html

"The Date line (formerly "Posted") is the date, in a format that
must be acceptable both to the ARPANET and to the getdate routine,
that the article was originally posted to the network. This date
remains unchanged as the article is propagated throughout the
network."

... and now
http://www.tcpipguide.com/free/t_Use...lHeaders-2.htm

"Date: The date and time that the message was originally
posted to Usenet. This is usually the
date/time that the user submitted the article to his
or her local NNTP server.

which means the posts will be within a second or two of each other, at
the most.

Date: Fri, 05 Dec 2014 16:10:29 -0500


this is yet another one of your absurd nitpicking rants since you have
absolutely nothing else to argue about.

who the **** cares if there was a message id anyway? unless you have a
****ty news server (which apparently you do, but that's your problem,
not mine), they posts show up together, and as i said, someone would
have either *just* seen the other post or realize they were about to
see it.

Jeez! Why are you frothing at the mouth?

because you're arguing about something *completely* irrelevant.

Citing a message ID is arguing?

no.

bitching that it wasn't included is.

it also has absolutely nothing to do with the topic and is yet another
one of your ridiculous diversions.

the two messages were posted at the same time. if your news server sees
it differently, then call your news server admin or switch to a server
that's not broken.

the time stamp makes absolutely no difference whatsoever? what matters
is the *contents*, which you are completely ignoring so that you can
babble.

The two different times of posting explain why I received your
articles in the reverse order in which you intended to send them.

i didn't intend to send them in any order.

the order they get posted is indeterminate. i queue up a batch and post
them en masse, which are sent over multiple newsserver connections.
that means some might end up being posted at the same time. it also
means that a couple of shorter messages could get posted during the
time a longer message is being sent on a different connection. the
entire batch usually takes a few seconds, total.

if you see variations of minutes (or really anything more than a few
seconds), then your server is broken. period.
--

Regards,

Eric Stevens

On Mon, 08 Dec 2014 10:33:29 -0500, nospam
wrote:

In article , Eric Stevens
wrote:


both messages were written locally and posted as a batch at the same
time, which means there was no message id when i wrote them or when
they were posted.

OK. I see that. There are three minutes separating the two messages. I
would have thought they were dated and time stamped when they were
posted, not when you put finger to key board.

your news server sucks. both messages were posted within a fraction of
a second of each other. there should not be a 3 minute delay. there
should not even be a 3 *second* delay. at the most, they should differ
by one second, if one was made slightly before the second clicked over.

Nothing to do with my news server. The time stamp is applied at your
end.

it's not at my end.

both messages were posted within a fraction of a second of each other.

From 1987 http://www.w3.org/Protocols/rfc850/rfc850.html

"The Date line (formerly "Posted") is the date, in a format that
must be acceptable both to the ARPANET and to the getdate routine,
that the article was originally posted to the network. This date
remains unchanged as the article is propagated throughout the
network."

... and now
http://www.tcpipguide.com/free/t_Use...lHeaders-2.htm

"Date: The date and time that the message was originally
posted to Usenet. This is usually the
date/time that the user submitted the article to his
or her local NNTP server.

which means the posts will be within a second or two of each other, at
the most.

Date: Fri, 05 Dec 2014 16:10:32 -0500

this is yet another one of your absurd nitpicking rants since you have
absolutely nothing else to argue about.

who the **** cares if there was a message id anyway? unless you have a
****ty news server (which apparently you do, but that's your problem,
not mine), they posts show up together, and as i said, someone would
have either *just* seen the other post or realize they were about to
see it.

Jeez! Why are you frothing at the mouth?

because you're arguing about something *completely* irrelevant.

Citing a message ID is arguing?

no.

bitching that it wasn't included is.

it also has absolutely nothing to do with the topic and is yet another
one of your ridiculous diversions.

the two messages were posted at the same time. if your news server sees
it differently, then call your news server admin or switch to a server
that's not broken.

the time stamp makes absolutely no difference whatsoever? what matters
is the *contents*, which you are completely ignoring so that you can
babble.

The two different times of posting explain why I received your
articles in the reverse order in which you intended to send them.

i didn't intend to send them in any order.

the order they get posted is indeterminate. i queue up a batch and post
them en masse, which are sent over multiple newsserver connections.
that means some might end up being posted at the same time. it also
means that a couple of shorter messages could get posted during the
time a longer message is being sent on a different connection. the
entire batch usually takes a few seconds, total.

if you see variations of minutes (or really anything more than a few
seconds), then your server is broken. period.
--

Regards,

Eric Stevens

On Mon, 08 Dec 2014 10:33:29 -0500, nospam
wrote:

In article , Eric Stevens
wrote:


both messages were written locally and posted as a batch at the same
time, which means there was no message id when i wrote them or when
they were posted.

OK. I see that. There are three minutes separating the two messages. I
would have thought they were dated and time stamped when they were
posted, not when you put finger to key board.

your news server sucks. both messages were posted within a fraction of
a second of each other. there should not be a 3 minute delay. there
should not even be a 3 *second* delay. at the most, they should differ
by one second, if one was made slightly before the second clicked over.

Nothing to do with my news server. The time stamp is applied at your
end.

it's not at my end.

both messages were posted within a fraction of a second of each other.

From 1987 http://www.w3.org/Protocols/rfc850/rfc850.html

"The Date line (formerly "Posted") is the date, in a format that
must be acceptable both to the ARPANET and to the getdate routine,
that the article was originally posted to the network. This date
remains unchanged as the article is propagated throughout the
network."

... and now
http://www.tcpipguide.com/free/t_Use...lHeaders-2.htm

"Date: The date and time that the message was originally
posted to Usenet. This is usually the
date/time that the user submitted the article to his
or her local NNTP server.

which means the posts will be within a second or two of each other, at
the most.

Date: Fri, 05 Dec 2014 16:10:29 -0500
Date: Fri, 05 Dec 2014 16:10:32 -0500

4 seconds. Not 4 minutes as I orginally wrote.

this is yet another one of your absurd nitpicking rants since you have
absolutely nothing else to argue about.

who the **** cares if there was a message id anyway? unless you have a
****ty news server (which apparently you do, but that's your problem,
not mine), they posts show up together, and as i said, someone would
have either *just* seen the other post or realize they were about to
see it.

Jeez! Why are you frothing at the mouth?

because you're arguing about something *completely* irrelevant.

Citing a message ID is arguing?

no.

bitching that it wasn't included is.

That wasn't bitching. I was pointing out that just saying "other
message" is not very helpful. What other message?

--- snip ---
--

Regards,

Eric Stevens

On Mon, 08 Dec 2014 10:33:42 -0500, nospam
wrote:

In article , Sandman
wrote:

Nothing to do with my news server. The time stamp is applied at
your end.

it's not at my end.

both messages were posted within a fraction of a second of each
other.

Your news client sets the date, and apparently it set the date to the time
of writing it, not the time of pushing it to the server. So three minutes
apart is the time it took you to write the first and start the second.

interesting theory, but it's completely wrong.

even though i know you're full of ****, i tested it anyway. i made
several posts to other threads, written several over an hour apart.

the time stamps showed the time the post was actually posted to the
newsserver, not the time the post was begun or completed at my end.

after posting the batch, all of the posts were at the most, within a
couple of seconds of each other, confirmed on two different servers.

as i said, the problem is not at my end.

not that the time stamps have *any* relevance to the topic. it's
nothing more than another ridiculous diversion from eric.

I was just explaining why your "see other message" was not helpful.
--

Regards,

Eric Stevens

In article , Eric Stevens
wrote:

which means the posts will be within a second or two of each other, at
the most.

Date: Fri, 05 Dec 2014 16:10:29 -0500

In article , Eric Stevens
wrote:

Date: Fri, 05 Dec 2014 16:10:32 -0500

in other words, you can't tell time.

the posts at *your* end are 3 seconds apart, not 3 minutes.

i have no idea where you came up with 3 minutes, but you ought to
figure that out for your own benefit. the time stamps *you* gave do not
show 3 minutes.