timestamps
August Muench wrote on Jul 10, 2008
hi,
sort of a strange problem with timestamps and IRAF. Running iraf 2.14 on Mac OSX 10.5.4 on a Mac Pro.
basically, imreplace seems to be setting a timestamp 1 hour slow. I've done this a couple of times now with different files and introduced different operations before trying imreplace -- always slow by 1 hour. Operations like imcopy, imarith, and imcombine produce correct timestamps.
Digging a bit deeper into the metadata (stat -x and GetFileInfo) indicates that the modification and creation timestamps are being incorrectly set. The creation timestamp prob just follows the modification timestamp in Mac OS X.
a search of the forums gave archived instances from the mid 90's regarding similar problems so perhaps it is IRAF and not my machine! Or some funny business with mac's metadata but I would not know where to look for that. But 1 hour slow is suspiciously like a daylight saving time prob.
- gus
Example:
ecl> imcopy
Input images (Ser03_POSS2_Red_mosaic.fits):
Output images or directory (Ser03_POSS2_Red_mosaic_weight.fits):
Ser03_POSS2_Red_mosaic.fits -> Ser03_POSS2_Red_mosaic_weight.fits
ecl> e ls
ls -l Ser03_POSS2_Red_mosaic*.fits
-rw-r--r--@ 1 aamn staff 103711680 Jul 1 15:46 Ser03_POSS2_Red_mosaic.fits
-rw-r--r-- 1 aamn staff 103714560 Jul 10 10:38 Ser03_POSS2_Red_mosaic_weight.fits
ecl> imarith
Operand image or numerical constant: Ser03_POSS2_Red_mosaic_weight.fits
Operator (+|-|*|/|min|max) (+): *
Operand image or numerical constant: 3
Resultant image: Ser03_POSS2_Red_mosaic_weight2.fits
ecl> e ls
ls -l Ser03_POSS2_Red_mosaic*.fits
-rw-r--r--@ 1 aamn staff 103711680 Jul 1 15:46 Ser03_POSS2_Red_mosaic.fits
-rw-r--r-- 1 aamn staff 103714560 Jul 10 10:38 Ser03_POSS2_Red_mosaic_weight.fits
-rw-r--r-- 1 aamn staff 103714560 Jul 10 10:39 Ser03_POSS2_Red_mosaic_weight2.fits
ecl> imreplace
Images to be edited (Ser03_POSS2_Red_mosaic_weight.fits): Ser03_POSS2_Red_mosaic_weight2.fits
Replacement pixel value (1.):
ecl> e ls
ls -l Ser03_POSS2_Red_mosaic*.fits
-rw-r--r--@ 1 aamn staff 103711680 Jul 1 15:46 Ser03_POSS2_Red_mosaic.fits
-rw-r--r-- 1 aamn staff 103714560 Jul 10 10:38 Ser03_POSS2_Red_mosaic_weight.fits
-rw-r--r-- 1 aamn staff 103714560 Jul 10 09:39 Ser03_POSS2_Red_mosaic_weight2.fits
ecl>!stat -x Ser03_POSS2_Red_mosaic_weight*fits
File: "Ser03_POSS2_Red_mosaic_weight.fits"
Size: 103714560 FileType: Regular File
Device: 14,2 Inode: 16869726 Links: 1
Access: Thu Jul 10 11:10:57 2008
Modify: Thu Jul 10 10:38:53 2008
Change: Thu Jul 10 10:38:53 2008
File: "Ser03_POSS2_Red_mosaic_weight2.fits"
Size: 103714560 FileType: Regular File
Device: 14,2 Inode: 16869729 Links: 1
Access: Thu Jul 10 11:10:59 2008
Modify: Thu Jul 10 09:39:50 2008
Change: Thu Jul 10 10:40:12 2008
ecl> !/Developer/usr/bin/GetFileInfo Ser03_POSS2_Red_mosaic_weight2.fits
file: "####/Ser03_POSS2_Red_mosaic_weight2.fits"
type: ""
creator: ""
attributes: avbstclinmedz
created: 07/10/2008 09:39:50
modified: 07/10/2008 09:39:50
sort of a strange problem with timestamps and IRAF. Running iraf 2.14 on Mac OSX 10.5.4 on a Mac Pro.
basically, imreplace seems to be setting a timestamp 1 hour slow. I've done this a couple of times now with different files and introduced different operations before trying imreplace -- always slow by 1 hour. Operations like imcopy, imarith, and imcombine produce correct timestamps.
Digging a bit deeper into the metadata (stat -x and GetFileInfo) indicates that the modification and creation timestamps are being incorrectly set. The creation timestamp prob just follows the modification timestamp in Mac OS X.
a search of the forums gave archived instances from the mid 90's regarding similar problems so perhaps it is IRAF and not my machine! Or some funny business with mac's metadata but I would not know where to look for that. But 1 hour slow is suspiciously like a daylight saving time prob.
- gus
Example:
ecl> imcopy
Input images (Ser03_POSS2_Red_mosaic.fits):
Output images or directory (Ser03_POSS2_Red_mosaic_weight.fits):
Ser03_POSS2_Red_mosaic.fits -> Ser03_POSS2_Red_mosaic_weight.fits
ecl> e ls
ls -l Ser03_POSS2_Red_mosaic*.fits
-rw-r--r--@ 1 aamn staff 103711680 Jul 1 15:46 Ser03_POSS2_Red_mosaic.fits
-rw-r--r-- 1 aamn staff 103714560 Jul 10 10:38 Ser03_POSS2_Red_mosaic_weight.fits
ecl> imarith
Operand image or numerical constant: Ser03_POSS2_Red_mosaic_weight.fits
Operator (+|-|*|/|min|max) (+): *
Operand image or numerical constant: 3
Resultant image: Ser03_POSS2_Red_mosaic_weight2.fits
ecl> e ls
ls -l Ser03_POSS2_Red_mosaic*.fits
-rw-r--r--@ 1 aamn staff 103711680 Jul 1 15:46 Ser03_POSS2_Red_mosaic.fits
-rw-r--r-- 1 aamn staff 103714560 Jul 10 10:38 Ser03_POSS2_Red_mosaic_weight.fits
-rw-r--r-- 1 aamn staff 103714560 Jul 10 10:39 Ser03_POSS2_Red_mosaic_weight2.fits
ecl> imreplace
Images to be edited (Ser03_POSS2_Red_mosaic_weight.fits): Ser03_POSS2_Red_mosaic_weight2.fits
Replacement pixel value (1.):
ecl> e ls
ls -l Ser03_POSS2_Red_mosaic*.fits
-rw-r--r--@ 1 aamn staff 103711680 Jul 1 15:46 Ser03_POSS2_Red_mosaic.fits
-rw-r--r-- 1 aamn staff 103714560 Jul 10 10:38 Ser03_POSS2_Red_mosaic_weight.fits
-rw-r--r-- 1 aamn staff 103714560 Jul 10 09:39 Ser03_POSS2_Red_mosaic_weight2.fits
ecl>!stat -x Ser03_POSS2_Red_mosaic_weight*fits
File: "Ser03_POSS2_Red_mosaic_weight.fits"
Size: 103714560 FileType: Regular File
Device: 14,2 Inode: 16869726 Links: 1
Access: Thu Jul 10 11:10:57 2008
Modify: Thu Jul 10 10:38:53 2008
Change: Thu Jul 10 10:38:53 2008
File: "Ser03_POSS2_Red_mosaic_weight2.fits"
Size: 103714560 FileType: Regular File
Device: 14,2 Inode: 16869729 Links: 1
Access: Thu Jul 10 11:10:59 2008
Modify: Thu Jul 10 09:39:50 2008
Change: Thu Jul 10 10:40:12 2008
ecl> !/Developer/usr/bin/GetFileInfo Ser03_POSS2_Red_mosaic_weight2.fits
file: "####/Ser03_POSS2_Red_mosaic_weight2.fits"
type: ""
creator: ""
attributes: avbstclinmedz
created: 07/10/2008 09:39:50
modified: 07/10/2008 09:39:50
Mike Fitzpatrick wrote on Jul 10, 2008
Hi Gus,
There is indeed a known issue with DST on Mac systems that will be fixed in the next patch release. Being in Tucson, this isn't a problem we see ourselves...
Cheers,
-Mike
There is indeed a known issue with DST on Mac systems that will be fixed in the next patch release. Being in Tucson, this isn't a problem we see ourselves...
Cheers,
-Mike
Last post on Jul 10, 2008