What does PM's stand for?
It's her way of saying "You have a message, probably about how strongly you put your reply"
I did try to figure out how to put it nicely, but he said...Ah. I could have quoted the Vincent Vega character from Pulp Fiction: "That's a bold statement."
And I fully agree witht OP about LR supporting UTC. Keeping th vamera at that time prevents ME from mistakes. Ik used to travel (for pleasure), not much anymore. (Combodja in nov, that's all for this year).
How do you USA-citizens work: adjust avery tim you cross a time border?
It would be nice if LR could determine the local time from the GDP coordinates.
Aaaand because you agreed with me I'll deal with comments in other posts here. Then I'll be nicer ;-)
US-citizens probably range from normal consumers who don't have the time set unless the camera asked them to originally to those who are aware and adjust the time when they remember to. Those who are more serious probably stumble on some method, I've had to deal with timezones for a long time, so I stumbled on it the first time we hit a daylight savings time. Those who travel a lot will stumble on a fix much sooner
That said, a poll is in order! If I get time I'll put one together, but it won't be today. If someone wants to put some thought into a poll that'd be great.
Back to comments...
I didn't ask for a feature to be copied from Aperture, I was aware Aperture has some way of dealing with it. But it is very obvious that time has to be dealt with. Again, anyone who has to change their clocks twice a year will end up noticing it.
Anyone who was in the US Army is likely to be aware of "Zulu time", another way to say UTC. So the knowledge is out there of using a single time so you don't have to screw around. I wouldn't mind 1 time for the world, personally.
It seems clear the LR devs didn't deal with UTC because they had a nasty bug with time that they have only just (one hopes) put to rest (reference
http://www.adobeforums.com/webx/.3c'59'ff again).
Without having seen how Aperture does it, I'd store the time and offset from the camera, where available. On import I'd let a user say what time was used, with UTC being the choice at the top of the list (system time being 2nd). And then store time in UTC. I'd allow
displaying, at the user's option:
1) Time as originally recorded
2) Time shown as current local time keeping in mind any DST
3) Time shown
as if it was taken with the clock on the camera always kept to correct local time.
4) Time based on any arbitrary time zone (e.g. UTC)
5) Other (I can't think of everything off hand, check with others)
GPS's (what I think you are talking about) have accurate time at their heart, so one can only hope that would be used and respected and pre-fill-in the choices. Then it is up to the user to show things as expected.
Example:
Say you are in Boston for the 4th of July, which is normally -'5'' but it is summertime so it is -'4'', and you snap a picture of a pretty sailing ship at 2359 UTC (7:59 PM local time) and then another 2 minutes later. Storing things in UTC the pictures are taken on different days. Having the adjustment where you can say "I took this in EST5EDT" and it showing them as both being taken on the same day would be nice. But the stored format has *got* to be immutable (well for those who care or have to care) and it has to make it easy to always get it right (meaning, if I fly from Chicago, and I'm worried about getting the picture, the last thing I need is to worry about changing the time in my camera). Make it worse: imagine it is a wedding (queue flop sweat
If OP doesn't fiel a request I will.
Well, I think best is to file it anyway
I filed it. No number was returned, however. I think they triage submissions, laughing at some, puzzling over others, marking MANY as dups, entering a few. Ah, Victoria says for feature requests they count submissions. Hooray! Everybody submit this one!!
