Problem with exiftool and geosync, possibly related to daylight saving time
![Creative The name of the picture](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgO9GURib1T8z7lCwjOGLQaGtrueEthgQ8LO42ZX8cOfTqDK4jvDDpKkLFwf2J49kYCMNW7d4ABih_XCb_2UXdq5fPJDkoyg7-8g_YfRUot-XnaXkNYycsNp7lA5_TW9td0FFpLQ2APzKcZ/s1600/1.jpg)
![Creative The name of the picture](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYQ0N5W1qAOxLP7t7iOM6O6AzbZnkXUy16s7P_CWfOb5UbTQY_aDsc727chyphenhyphen5W4IppVNernMMQeaUFTB_rFzAd95_CDt-tnwN-nBx6JyUp2duGjPaL5-VgNO41AVsA_vu30EJcipdDG409/s400/Clash+Royale+CLAN+TAG%2523URR8PPP.png)
up vote
0
down vote
favorite
I wanted to geotag all my vacation photos with exiftool
as follows:
exiftool -geotag "*.gpx"
-geosync "19:25:42Z@IMG_7882.jpg"
-geosync "09:16:34Z@IMG_9798.jpg"
-ext .jpg .
where IMG_7802.jpg is a photo of my computer clock displaying 20:25:42 MEZ on 01 March 2018 (=19:25:42 Zulu), and similarly IMG_9798.jpg is a photo of my computer clock displaying 11:16:34 MESZ on 31 March 2018 (=09:16:34 Zulu). I used two such (bracketing) reference images in order to account for drift (and, indeed, the camera clock seems to have gained 26 seconds during that month).
The adjustment went fine for the reference images:
$ exiftool -datetimeoriginal -gpsdatetime IMG_7882.jpg
Date/Time Original : 2018:03:01 20:25:42
GPS Date/Time : 2018:03:01 19:25:42Z
$ exiftool -datetimeoriginal -gpsdatetime IMG_9798.jpg
Date/Time Original : 2018:03:31 10:17:00
GPS Date/Time : 2018:03:31 09:16:34Z
But for intermediate images, the computed GPS time is significantly off, e.g. by about half an hour in the following example (a GPS time of approximately 14:32Z is what I'd expect)
$ exiftool -datetimeoriginal -gpsdatetime IMG_8888.jpg
Date/Time Original : 2018:03:17 15:32:22
GPS Date/Time : 2018:03:17 15:04:13.45312997Z
Accordingly, the computed longitudes and latitudes are quite far off as well.
My educated guess is that the problem is related to the daylight saving time that started in Germany between the two reference images. Apparently, exiftool
interpretes DateTimeOriginal in local time (so first MEZ = +0100
and later MESZ = +0200
) whereas the camera clock just keeps on ticking (approximately with a +0100
offset throughout).
Q: How can I tell exiftool
to not assume that the camera clock (DateTimeOriginal) follows any daylight saving time rules?
camera clock timezone exiftool
add a comment |Â
up vote
0
down vote
favorite
I wanted to geotag all my vacation photos with exiftool
as follows:
exiftool -geotag "*.gpx"
-geosync "19:25:42Z@IMG_7882.jpg"
-geosync "09:16:34Z@IMG_9798.jpg"
-ext .jpg .
where IMG_7802.jpg is a photo of my computer clock displaying 20:25:42 MEZ on 01 March 2018 (=19:25:42 Zulu), and similarly IMG_9798.jpg is a photo of my computer clock displaying 11:16:34 MESZ on 31 March 2018 (=09:16:34 Zulu). I used two such (bracketing) reference images in order to account for drift (and, indeed, the camera clock seems to have gained 26 seconds during that month).
The adjustment went fine for the reference images:
$ exiftool -datetimeoriginal -gpsdatetime IMG_7882.jpg
Date/Time Original : 2018:03:01 20:25:42
GPS Date/Time : 2018:03:01 19:25:42Z
$ exiftool -datetimeoriginal -gpsdatetime IMG_9798.jpg
Date/Time Original : 2018:03:31 10:17:00
GPS Date/Time : 2018:03:31 09:16:34Z
But for intermediate images, the computed GPS time is significantly off, e.g. by about half an hour in the following example (a GPS time of approximately 14:32Z is what I'd expect)
$ exiftool -datetimeoriginal -gpsdatetime IMG_8888.jpg
Date/Time Original : 2018:03:17 15:32:22
GPS Date/Time : 2018:03:17 15:04:13.45312997Z
Accordingly, the computed longitudes and latitudes are quite far off as well.
My educated guess is that the problem is related to the daylight saving time that started in Germany between the two reference images. Apparently, exiftool
interpretes DateTimeOriginal in local time (so first MEZ = +0100
and later MESZ = +0200
) whereas the camera clock just keeps on ticking (approximately with a +0100
offset throughout).
Q: How can I tell exiftool
to not assume that the camera clock (DateTimeOriginal) follows any daylight saving time rules?
camera clock timezone exiftool
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I wanted to geotag all my vacation photos with exiftool
as follows:
exiftool -geotag "*.gpx"
-geosync "19:25:42Z@IMG_7882.jpg"
-geosync "09:16:34Z@IMG_9798.jpg"
-ext .jpg .
where IMG_7802.jpg is a photo of my computer clock displaying 20:25:42 MEZ on 01 March 2018 (=19:25:42 Zulu), and similarly IMG_9798.jpg is a photo of my computer clock displaying 11:16:34 MESZ on 31 March 2018 (=09:16:34 Zulu). I used two such (bracketing) reference images in order to account for drift (and, indeed, the camera clock seems to have gained 26 seconds during that month).
The adjustment went fine for the reference images:
$ exiftool -datetimeoriginal -gpsdatetime IMG_7882.jpg
Date/Time Original : 2018:03:01 20:25:42
GPS Date/Time : 2018:03:01 19:25:42Z
$ exiftool -datetimeoriginal -gpsdatetime IMG_9798.jpg
Date/Time Original : 2018:03:31 10:17:00
GPS Date/Time : 2018:03:31 09:16:34Z
But for intermediate images, the computed GPS time is significantly off, e.g. by about half an hour in the following example (a GPS time of approximately 14:32Z is what I'd expect)
$ exiftool -datetimeoriginal -gpsdatetime IMG_8888.jpg
Date/Time Original : 2018:03:17 15:32:22
GPS Date/Time : 2018:03:17 15:04:13.45312997Z
Accordingly, the computed longitudes and latitudes are quite far off as well.
My educated guess is that the problem is related to the daylight saving time that started in Germany between the two reference images. Apparently, exiftool
interpretes DateTimeOriginal in local time (so first MEZ = +0100
and later MESZ = +0200
) whereas the camera clock just keeps on ticking (approximately with a +0100
offset throughout).
Q: How can I tell exiftool
to not assume that the camera clock (DateTimeOriginal) follows any daylight saving time rules?
camera clock timezone exiftool
I wanted to geotag all my vacation photos with exiftool
as follows:
exiftool -geotag "*.gpx"
-geosync "19:25:42Z@IMG_7882.jpg"
-geosync "09:16:34Z@IMG_9798.jpg"
-ext .jpg .
where IMG_7802.jpg is a photo of my computer clock displaying 20:25:42 MEZ on 01 March 2018 (=19:25:42 Zulu), and similarly IMG_9798.jpg is a photo of my computer clock displaying 11:16:34 MESZ on 31 March 2018 (=09:16:34 Zulu). I used two such (bracketing) reference images in order to account for drift (and, indeed, the camera clock seems to have gained 26 seconds during that month).
The adjustment went fine for the reference images:
$ exiftool -datetimeoriginal -gpsdatetime IMG_7882.jpg
Date/Time Original : 2018:03:01 20:25:42
GPS Date/Time : 2018:03:01 19:25:42Z
$ exiftool -datetimeoriginal -gpsdatetime IMG_9798.jpg
Date/Time Original : 2018:03:31 10:17:00
GPS Date/Time : 2018:03:31 09:16:34Z
But for intermediate images, the computed GPS time is significantly off, e.g. by about half an hour in the following example (a GPS time of approximately 14:32Z is what I'd expect)
$ exiftool -datetimeoriginal -gpsdatetime IMG_8888.jpg
Date/Time Original : 2018:03:17 15:32:22
GPS Date/Time : 2018:03:17 15:04:13.45312997Z
Accordingly, the computed longitudes and latitudes are quite far off as well.
My educated guess is that the problem is related to the daylight saving time that started in Germany between the two reference images. Apparently, exiftool
interpretes DateTimeOriginal in local time (so first MEZ = +0100
and later MESZ = +0200
) whereas the camera clock just keeps on ticking (approximately with a +0100
offset throughout).
Q: How can I tell exiftool
to not assume that the camera clock (DateTimeOriginal) follows any daylight saving time rules?
camera clock timezone exiftool
camera clock timezone exiftool
asked Apr 1 at 13:54
![](https://i.stack.imgur.com/hnO1y.jpg?s=32&g=1)
![](https://i.stack.imgur.com/hnO1y.jpg?s=32&g=1)
Hagen von Eitzen
4211
4211
add a comment |Â
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
0
down vote
accepted
Yes, the problem ultimately comes from the DST switching and the fact that the DateTimeOriginal
is interpreted as local time (hence subject to DST changes). There seem to be several ways to workaround the problem
A) change the local time zone
I.e., change the locale settings so that your system is in a time zone that does not switch DST during the time interval and then invoke exiftool
as in the OP.
However, I won't recommend this. You'd also have to be careful that the selected DST-less time zone is not too far off or else exiftool
might be off by a full day with some of its guesses. It seems that West Africa Time (as used in Nigeria) would have worked in my specific situation.
B) Add Time zone information to DateTimeOriginal
first
I.e., first run
exiftool '-DateTimeOriginal<$DateTimeOriginal+01:00' -ext .jpg .
as +01:00 was effectively the camara's time zone all along.
This might have been advisable anyway to prevent future confusion about the time the images were taken. Then again, we are about to add the unambiguous and adjusted GPS time anyway.
I ended up doing
C) Use -geotime
and explicit reference times with time zone specification
... as in
exiftool -geotag "*.gpx"
-geosync "19:25:42Z@2018:03:01 20:25:42+01:00"
-geosync "09:16:34Z@2018:03:31 10:17:00+01:00"
'-geotime<$DateTimeOriginal+01:00'
-ext .jpg .
This tells exiftool
to use DateTimeOriginal
with specified time zone instead of interpreted as local time. Unfortunately, this only applies to the times read from the images being modified, not for the times read form the reference images (even if one changes the parameter order), so that the explicit times (with time zone) had to be used instead of file references.
Actually, since my refernce images had already been assigned correct GPS times from the first experiments, what I really did was a mix of B and C: I did the adjustment suggested in "B" only for the two reference images:
$ exiftool '-DateTimeOriginal<$DateTimeOriginal+01:00' IMG_7882.jpg IMG_9798.jpg
so that their DateTimeOriginal
data had time zone info:
$ exiftool -datetimeoriginal -gpsdatetime IMG_7882.jpg
Date/Time Original : 2018:03:01 20:25:42.00+01:00
GPS Date/Time : 2018:03:01 19:25:42Z
$ exiftool -datetimeoriginal -gpsdatetime IMG_9798.jpg
Date/Time Original : 2018:03:31 10:17:00.00+01:00
GPS Date/Time : 2018:03:31 09:16:34Z
After that I could use the reference images by their file names
exiftool -geotag "*.gpx"
-geosync "IMG_7882.jpg"
-geosync "IMG_9798.jpg"
'-geotime<$DateTimeOriginal+01:00'
-ext .jpg .
produces the desired result for the GPS times (and consequently for the GPS coordinates) also for intermediate images:
$ exiftool -datetimeoriginal -gpsdatetime IMG_8888.jpg
Date/Time Original : 2018:03:17 15:32:22
GPS Date/Time : 2018:03:17 14:32:08.114220008Z
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
accepted
Yes, the problem ultimately comes from the DST switching and the fact that the DateTimeOriginal
is interpreted as local time (hence subject to DST changes). There seem to be several ways to workaround the problem
A) change the local time zone
I.e., change the locale settings so that your system is in a time zone that does not switch DST during the time interval and then invoke exiftool
as in the OP.
However, I won't recommend this. You'd also have to be careful that the selected DST-less time zone is not too far off or else exiftool
might be off by a full day with some of its guesses. It seems that West Africa Time (as used in Nigeria) would have worked in my specific situation.
B) Add Time zone information to DateTimeOriginal
first
I.e., first run
exiftool '-DateTimeOriginal<$DateTimeOriginal+01:00' -ext .jpg .
as +01:00 was effectively the camara's time zone all along.
This might have been advisable anyway to prevent future confusion about the time the images were taken. Then again, we are about to add the unambiguous and adjusted GPS time anyway.
I ended up doing
C) Use -geotime
and explicit reference times with time zone specification
... as in
exiftool -geotag "*.gpx"
-geosync "19:25:42Z@2018:03:01 20:25:42+01:00"
-geosync "09:16:34Z@2018:03:31 10:17:00+01:00"
'-geotime<$DateTimeOriginal+01:00'
-ext .jpg .
This tells exiftool
to use DateTimeOriginal
with specified time zone instead of interpreted as local time. Unfortunately, this only applies to the times read from the images being modified, not for the times read form the reference images (even if one changes the parameter order), so that the explicit times (with time zone) had to be used instead of file references.
Actually, since my refernce images had already been assigned correct GPS times from the first experiments, what I really did was a mix of B and C: I did the adjustment suggested in "B" only for the two reference images:
$ exiftool '-DateTimeOriginal<$DateTimeOriginal+01:00' IMG_7882.jpg IMG_9798.jpg
so that their DateTimeOriginal
data had time zone info:
$ exiftool -datetimeoriginal -gpsdatetime IMG_7882.jpg
Date/Time Original : 2018:03:01 20:25:42.00+01:00
GPS Date/Time : 2018:03:01 19:25:42Z
$ exiftool -datetimeoriginal -gpsdatetime IMG_9798.jpg
Date/Time Original : 2018:03:31 10:17:00.00+01:00
GPS Date/Time : 2018:03:31 09:16:34Z
After that I could use the reference images by their file names
exiftool -geotag "*.gpx"
-geosync "IMG_7882.jpg"
-geosync "IMG_9798.jpg"
'-geotime<$DateTimeOriginal+01:00'
-ext .jpg .
produces the desired result for the GPS times (and consequently for the GPS coordinates) also for intermediate images:
$ exiftool -datetimeoriginal -gpsdatetime IMG_8888.jpg
Date/Time Original : 2018:03:17 15:32:22
GPS Date/Time : 2018:03:17 14:32:08.114220008Z
add a comment |Â
up vote
0
down vote
accepted
Yes, the problem ultimately comes from the DST switching and the fact that the DateTimeOriginal
is interpreted as local time (hence subject to DST changes). There seem to be several ways to workaround the problem
A) change the local time zone
I.e., change the locale settings so that your system is in a time zone that does not switch DST during the time interval and then invoke exiftool
as in the OP.
However, I won't recommend this. You'd also have to be careful that the selected DST-less time zone is not too far off or else exiftool
might be off by a full day with some of its guesses. It seems that West Africa Time (as used in Nigeria) would have worked in my specific situation.
B) Add Time zone information to DateTimeOriginal
first
I.e., first run
exiftool '-DateTimeOriginal<$DateTimeOriginal+01:00' -ext .jpg .
as +01:00 was effectively the camara's time zone all along.
This might have been advisable anyway to prevent future confusion about the time the images were taken. Then again, we are about to add the unambiguous and adjusted GPS time anyway.
I ended up doing
C) Use -geotime
and explicit reference times with time zone specification
... as in
exiftool -geotag "*.gpx"
-geosync "19:25:42Z@2018:03:01 20:25:42+01:00"
-geosync "09:16:34Z@2018:03:31 10:17:00+01:00"
'-geotime<$DateTimeOriginal+01:00'
-ext .jpg .
This tells exiftool
to use DateTimeOriginal
with specified time zone instead of interpreted as local time. Unfortunately, this only applies to the times read from the images being modified, not for the times read form the reference images (even if one changes the parameter order), so that the explicit times (with time zone) had to be used instead of file references.
Actually, since my refernce images had already been assigned correct GPS times from the first experiments, what I really did was a mix of B and C: I did the adjustment suggested in "B" only for the two reference images:
$ exiftool '-DateTimeOriginal<$DateTimeOriginal+01:00' IMG_7882.jpg IMG_9798.jpg
so that their DateTimeOriginal
data had time zone info:
$ exiftool -datetimeoriginal -gpsdatetime IMG_7882.jpg
Date/Time Original : 2018:03:01 20:25:42.00+01:00
GPS Date/Time : 2018:03:01 19:25:42Z
$ exiftool -datetimeoriginal -gpsdatetime IMG_9798.jpg
Date/Time Original : 2018:03:31 10:17:00.00+01:00
GPS Date/Time : 2018:03:31 09:16:34Z
After that I could use the reference images by their file names
exiftool -geotag "*.gpx"
-geosync "IMG_7882.jpg"
-geosync "IMG_9798.jpg"
'-geotime<$DateTimeOriginal+01:00'
-ext .jpg .
produces the desired result for the GPS times (and consequently for the GPS coordinates) also for intermediate images:
$ exiftool -datetimeoriginal -gpsdatetime IMG_8888.jpg
Date/Time Original : 2018:03:17 15:32:22
GPS Date/Time : 2018:03:17 14:32:08.114220008Z
add a comment |Â
up vote
0
down vote
accepted
up vote
0
down vote
accepted
Yes, the problem ultimately comes from the DST switching and the fact that the DateTimeOriginal
is interpreted as local time (hence subject to DST changes). There seem to be several ways to workaround the problem
A) change the local time zone
I.e., change the locale settings so that your system is in a time zone that does not switch DST during the time interval and then invoke exiftool
as in the OP.
However, I won't recommend this. You'd also have to be careful that the selected DST-less time zone is not too far off or else exiftool
might be off by a full day with some of its guesses. It seems that West Africa Time (as used in Nigeria) would have worked in my specific situation.
B) Add Time zone information to DateTimeOriginal
first
I.e., first run
exiftool '-DateTimeOriginal<$DateTimeOriginal+01:00' -ext .jpg .
as +01:00 was effectively the camara's time zone all along.
This might have been advisable anyway to prevent future confusion about the time the images were taken. Then again, we are about to add the unambiguous and adjusted GPS time anyway.
I ended up doing
C) Use -geotime
and explicit reference times with time zone specification
... as in
exiftool -geotag "*.gpx"
-geosync "19:25:42Z@2018:03:01 20:25:42+01:00"
-geosync "09:16:34Z@2018:03:31 10:17:00+01:00"
'-geotime<$DateTimeOriginal+01:00'
-ext .jpg .
This tells exiftool
to use DateTimeOriginal
with specified time zone instead of interpreted as local time. Unfortunately, this only applies to the times read from the images being modified, not for the times read form the reference images (even if one changes the parameter order), so that the explicit times (with time zone) had to be used instead of file references.
Actually, since my refernce images had already been assigned correct GPS times from the first experiments, what I really did was a mix of B and C: I did the adjustment suggested in "B" only for the two reference images:
$ exiftool '-DateTimeOriginal<$DateTimeOriginal+01:00' IMG_7882.jpg IMG_9798.jpg
so that their DateTimeOriginal
data had time zone info:
$ exiftool -datetimeoriginal -gpsdatetime IMG_7882.jpg
Date/Time Original : 2018:03:01 20:25:42.00+01:00
GPS Date/Time : 2018:03:01 19:25:42Z
$ exiftool -datetimeoriginal -gpsdatetime IMG_9798.jpg
Date/Time Original : 2018:03:31 10:17:00.00+01:00
GPS Date/Time : 2018:03:31 09:16:34Z
After that I could use the reference images by their file names
exiftool -geotag "*.gpx"
-geosync "IMG_7882.jpg"
-geosync "IMG_9798.jpg"
'-geotime<$DateTimeOriginal+01:00'
-ext .jpg .
produces the desired result for the GPS times (and consequently for the GPS coordinates) also for intermediate images:
$ exiftool -datetimeoriginal -gpsdatetime IMG_8888.jpg
Date/Time Original : 2018:03:17 15:32:22
GPS Date/Time : 2018:03:17 14:32:08.114220008Z
Yes, the problem ultimately comes from the DST switching and the fact that the DateTimeOriginal
is interpreted as local time (hence subject to DST changes). There seem to be several ways to workaround the problem
A) change the local time zone
I.e., change the locale settings so that your system is in a time zone that does not switch DST during the time interval and then invoke exiftool
as in the OP.
However, I won't recommend this. You'd also have to be careful that the selected DST-less time zone is not too far off or else exiftool
might be off by a full day with some of its guesses. It seems that West Africa Time (as used in Nigeria) would have worked in my specific situation.
B) Add Time zone information to DateTimeOriginal
first
I.e., first run
exiftool '-DateTimeOriginal<$DateTimeOriginal+01:00' -ext .jpg .
as +01:00 was effectively the camara's time zone all along.
This might have been advisable anyway to prevent future confusion about the time the images were taken. Then again, we are about to add the unambiguous and adjusted GPS time anyway.
I ended up doing
C) Use -geotime
and explicit reference times with time zone specification
... as in
exiftool -geotag "*.gpx"
-geosync "19:25:42Z@2018:03:01 20:25:42+01:00"
-geosync "09:16:34Z@2018:03:31 10:17:00+01:00"
'-geotime<$DateTimeOriginal+01:00'
-ext .jpg .
This tells exiftool
to use DateTimeOriginal
with specified time zone instead of interpreted as local time. Unfortunately, this only applies to the times read from the images being modified, not for the times read form the reference images (even if one changes the parameter order), so that the explicit times (with time zone) had to be used instead of file references.
Actually, since my refernce images had already been assigned correct GPS times from the first experiments, what I really did was a mix of B and C: I did the adjustment suggested in "B" only for the two reference images:
$ exiftool '-DateTimeOriginal<$DateTimeOriginal+01:00' IMG_7882.jpg IMG_9798.jpg
so that their DateTimeOriginal
data had time zone info:
$ exiftool -datetimeoriginal -gpsdatetime IMG_7882.jpg
Date/Time Original : 2018:03:01 20:25:42.00+01:00
GPS Date/Time : 2018:03:01 19:25:42Z
$ exiftool -datetimeoriginal -gpsdatetime IMG_9798.jpg
Date/Time Original : 2018:03:31 10:17:00.00+01:00
GPS Date/Time : 2018:03:31 09:16:34Z
After that I could use the reference images by their file names
exiftool -geotag "*.gpx"
-geosync "IMG_7882.jpg"
-geosync "IMG_9798.jpg"
'-geotime<$DateTimeOriginal+01:00'
-ext .jpg .
produces the desired result for the GPS times (and consequently for the GPS coordinates) also for intermediate images:
$ exiftool -datetimeoriginal -gpsdatetime IMG_8888.jpg
Date/Time Original : 2018:03:17 15:32:22
GPS Date/Time : 2018:03:17 14:32:08.114220008Z
answered Apr 1 at 17:54
![](https://i.stack.imgur.com/hnO1y.jpg?s=32&g=1)
![](https://i.stack.imgur.com/hnO1y.jpg?s=32&g=1)
Hagen von Eitzen
4211
4211
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1021063%2fproblem-with-exiftool-and-geosync-possibly-related-to-daylight-saving-time%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password