I found that the PAR/REC files and the NIFTI dataset were essentially identical. There were differences because of scaling and because of a shift in the origin between the two. Philips PAR/REC datasets are generally scaled values. To compute the actual value, the stored value is multiplied by a scale factor and an intercept is added (there are sometimes additional complications for some datasets, but this is usually the case for EPI data). The scale factors and intercept values are available in the PAR file in the "(re)scale columns". EPI data typically has the same scale factors throughout the dataset, so only the first one is needed here. The NIFTI file also shows the same scale factor. Additionally, this information can be found in the DICOM data if you have it under the tags '0028,1052' and '0028,1053', the IMG rescale_intercept and rescale_slope, respectively. Note these factors are not typically important for EPI data because all factors are the same across TRs and are typically scaled to a mean anyway. The origin shift is a single voxel difference we had let Philips know about some time ago, but it's probably not critical.

Back to your actual question - the data are the same, but the fields in either the PAR/REC or NIFTI do not seem to identify any information about timing. I would imagine the data does not have any slice timing correction done, but Philips would be best to answer that for sure. The 3dPARtoAFNI.pl script assumes all slices are acquired simultaneously.

You can duplicate my test with these commands:

3dPAR2AFNI.pl epi.PAR
# the scale factors are derived from the PAR dataset below
3dcalc -a epi+orig. -expr 'a*1.442+1.23483e-003' -datum float -prefix epi_scl3 -overwrite
@Align_Centers -base epi.nii -no_cp -dset epi_scl3+orig.

nifti_tool -disp_hdr -infiles epi.nii

# === IMAGE INFORMATION ==========================================================
# sl ec dyn ph ty idx pix scan% rec size (re)scale window ........

1 1 1 1 0 2 0 16 100 80 80 0.00000 1.44200 1.23483e-003 1070 1860
2 1 1 1 0 2 1 16 100 80 80 0.00000 1.44200 1.23483e-003 1025 1781
3 1 1 1 0 2 2 16 100 80 80 0.00000 1.44200 1.23483e-003 865 1503
...


https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=MRICRO;af27b9c2.0801

https://groups.google.com/forum/?fromgroups=#!topic/comp.protocols.dicom/n5ybyj1Psno

http://dbic.dartmouth.edu/wiki/index.php/Slice_Timing_Correction