Date calculation Igor vs Apple

I'm trying to understand what seems to be a difference between the way Igor calculates the number of seconds since midnight Jan 1, 1904 and the way that Apple does it. I am looking at two key values extracted from iTunes XML file. These are Play_Date_UTC which is a date in the following format e.g. 2014-10-02T20:24:10Z and the other value is Play_Date which looks like number of seconds from 1904, in this example 3495129856. I calculate the number of seconds in Igor (see code below and in attached abbreviated file) and I consistently get a difference of either 3584 s or 3840 s. No other values. Assuming my code and Igor are correct, this would put the Apple time as 59m44s or 1h 4m before midnight Jan 1, 1904.

Can anyone explain what is going on? The difference is very small and doesn't really matter for what I'm doing, but I'm just wondering what can cause this. Please feel free to tell me if there is a more efficient way to do the calculation :)


Function DateRead()
    Wave /T Play_Date_UTC
    Variable nTracks=numpnts(Play_Date_UTC)
    Make/O /N=(nTracks) testdate2
    String olddate
    String expr="([[:digit:]]+)\-([[:digit:]]+)\-([[:digit:]]+)T([[:digit:]]+)\:([[:digit:]]+)\:([[:digit:]]+)Z"
    String yr,mh,dy,hh,mm,ss
    Variable i

    For(i=0; i<nTracks; i+=1)
        SplitString /E=(expr) olddate, yr,mh,dy,hh,mm,ss
time_test_exchange.pxp (51.46 KB)
Just a wild guess... could this be due to a difference between UTC and local time? Do you use daylight savings time in the UK?
Thanks for the comment. I don't think so. UTC is our time here in the UK - so no difference there. We do use daylight savings time in the summer, but the dates are from throughout the year. The difference is never zero only ever 3584 or 3840. I plotted difference vs date and could see no seasonal variation. It's a mystery!!
Shouldn't date/time waves be in double precision? ("/D")
In this case this would be a rounding issue....

Good point! Thank you. I changed that (and also the wave that I had parsed from XML) the procedure now gives a consistent 1 hr offset (3600 s). I can live with that, but I'm still wondering where it comes from. I guess there is an hour difference somewhere...
Try changing the timezone of your mac and check if the difference changes. If yes the 1h offset is definitly timezone related.