MacOSDate

A common (not exclusive) epoch used in plists is Jan 1, 2001 000000 UTC.
E.g. in Safari

See
http//www.forensicswiki.org/wiki/Apple_Safari

The epoch used in HFS/HFS+ is January 1, 1904 at 000000 localtime or UTC.

See
http//www.forensicswiki.org/wiki/Mac_OS_X

Both of them are still used.

If the timestamp is stored in localtime it already is corrected for timezone and daylight savings. E.g. if you would be in CEST and a timestamp is stored in CEST (summertime), you'll have to normalize the timestamp by -2h before comparing them to other timestamps in UTC. If the timestamp would be in CET (wintertime) this would be -1h.

If the timestamp is in UTC and you want to represent them in your localtime or the localtime of the system you're analyzing reverse the process.

Ok but if I found this number
3425616668

and I divide it by 86400 then I convert it in date (since 01/01/1904) I obtain
20/Jul/2012 08.11

this hour 08.11 is the real time or I have to add the +2 (timezone+DST ) of my zone?

1) If 08.11 is the real time it means that the IPod write the number using the seconds since 01/01/1904 + the seconds of the timezone + the seconds of the DST as its time settings on the device….
2) If 08.11 is ONLY the time past since 01/01/1904 in UTC/GMT+0 I have MANUALLY add the timezone +1 and DST +1 so I will obtain 10.11 as real time….

So, the question is…the device stores that number in absolute time in GMT+0 or does it store it including the seconds of the timezone and DST?

I found this experiment
http//comments.gmane.org/gmane.comp.ipod.gtkpod/3518
Thanks
bye

I just read this from Wikipedia
http//en.wikipedia.org/wiki/IPod

"Generally, if a new iPod (excluding the iPod shuffle) is initially plugged into a computer running Windows, it will be formatted with FAT32, and if initially plugged into a Mac running Mac OS X it will be formatted with HFS+.[23]"

So…If I get a new brand IPod Touch (2d generation) and I plug it for the first time into a computer running Windows…the file system becomes FAT32…is it right? So how does it work the timestamps since 01/01/1904 in FAT32? Like HFS (localtime) or like in HFS+ (UTC).?
Thanks

Pretty certain the storage on an iPod touch (an iOS device) is always going to be HFSx formatted.

And I think you might be getting confused between file system timestamps and the format of a time-stamp stored in a file? The two don't have to be related (consider if the time stamp was provided by a remote server for example).

AlexC I think you're right….I'm speaking about the number contained into playcount plist, so the lack is how the OS write this number inside it…in local time or UTC time? I guess in local time ….
Thanks

Ok but if I found this number
3425616668

and I divide it by 86400 then I convert it in date (since 01/01/1904) I obtain
20/Jul/2012 08.11

Using Python
print datetime.datetime( 1904, 1, 1 ) + datetime.timedelta( seconds=3425616668 )
2012-07-20 081108

So I would say that looks similar.

this hour 08.11 is the real time or I have to add the +2 (timezone+DST ) of my zone?

It is impossible to tell that solely from the timestamp.
Judging by the article you linked I would say it looks like the timestamp represents a date and time value in the local timezone.
However if I need to know this for a case, I make sure to do a reference test.

"HFS time" or "HFS+ time" is a short hand of expressing the date and time format as used in the HFS file system. So it applies to the type of timestamp not the file system. The only relation to the file system is that the timestamps are used in it. Referring to them as MacTime or MacOSXtime would be even more ambiguous.

The epoch used in HFS/HFS+ is January 1, 1904 at 000000 localtime or UTC.

See
http//www.forensicswiki.org/wiki/Mac_OS_X

Both of them are still used.

If the timestamp is stored in localtime it already is corrected for timezone and daylight savings. E.g. if you would be in CEST and a timestamp is stored in CEST (summertime), you'll have to normalize the timestamp by -2h before comparing them to other timestamps in UTC. If the timestamp would be in CET (wintertime) this would be -1h.

Note that in HFS+, there is exactly one timestamp that is in the local time zone – the volume creation date stored in the volume header. It's in local time for backwards-compatibility reasons. All other timestamps are in UTC.

Note that in HFS+, there is exactly one timestamp that is in the local time zone – the volume creation date stored in the volume header. It's in local time for backwards-compatibility reasons. All other timestamps are in UTC.

Again, the HFS in the name only indicates the origin of the timestamp you can find the same definition in
http//web.archive.org/web/20090214212148/http//developer.apple.com/technotes/tn/tn1150.html

indur for completeness also the information you refer to is in the same document
createDate
The date and time the folder was created. See HFS Plus Dates for a description of the format. Again, the createDate of the Volume Header is NOT stored in GMT; it is local time. (Further, if the volume has an HFS wrapper, the creation date in the MDB should be the same as the createDate in the Volume Header).