Hello,
I am trying to manipulate the contents of OOo files internally, which means unpacking the ZIPped ODT file, modifying the files, and then repackaging it. Turns out however that the files stored in the ODT package are incorrectly timestamped four hours in the future, which messes up the ZIP updating. Here's what I'm seeing (having saved template.odt seconds before):
dcorlette@moolap:/tmp> date
Sun Apr 13 15:02:12 EDT 2008
dcorlette@moolap:/tmp> ls -l template.odt
-rw-r--r-- 1 dcorlette users 89448 2008-04-13 15:02 template.odt
dcorlette@moolap:/tmp> unzip template.odt content.xml
Archive: template.odt
inflating: content.xml
dcorlette@moolap:/tmp> ls -l content.xml
-rw-r--r-- 1 dcorlette users 36558 2008-04-13 19:02 content.xml
As you can see, content.xml is incorrectly timestamped in the future. This seems like a bug to me, what do you think? Can you replicate this?
I'm running OOo 2.4.0.1 under SLED10 SP2.
[Issue] Incorrect internal timestamps in OOo file format?
[Issue] Incorrect internal timestamps in OOo file format?
Last edited by Hagar Delest on Tue Jun 10, 2008 1:35 pm, edited 2 times in total.
Reason: tagged the thread as issue.
Reason: tagged the thread as issue.
Re: Incorrect internal timestamps in OOo file format?
Can reproduce - and (maybe) explain: seems file timestamps are recorded in Central European Time.
This would explain a two hour difference here: German time differs 2 hours now (CEST used).
Could you confirm?
This would explain a two hour difference here: German time differs 2 hours now (CEST used).
Could you confirm?
Re: Incorrect internal timestamps in OOo file format?
The times for me seem to be UTC.
Why do you want to update the contents of the archive? Just replace the files that you've changed--that doesn't matter what the times are. I don't think you want to rely on the archive times for anything.
Why do you want to update the contents of the archive? Just replace the files that you've changed--that doesn't matter what the times are. I don't think you want to rely on the archive times for anything.
AOO4/LO5 • Linux • Fedora 23
Re: Incorrect internal timestamps in OOo file format?
So I'm in EDT as you can see from my 'date' command. I think that's 4 hrs off from UTC, so that would account for the 4 hour difference. But it would seem to me that if the files are stored in the ODT file in UTC, there should be a timezone indication or something in the ZIP.
To respond to the other post, what I'm doing in this case is using ant to extract the content.xml file, perform variable replacement, and then store it back in the ZIP. But the ant command, like 'zip -f' or 'zip -u', will only update ZIP archive members if the file you are updating is newer than the one in the archive. So when the archive timestamp is wrong, the archive member isn't correctly updated.
The only workaround I've thought of is to completely rebuild the ZIP file, which isn't efficient.
To respond to the other post, what I'm doing in this case is using ant to extract the content.xml file, perform variable replacement, and then store it back in the ZIP. But the ant command, like 'zip -f' or 'zip -u', will only update ZIP archive members if the file you are updating is newer than the one in the archive. So when the archive timestamp is wrong, the archive member isn't correctly updated.
The only workaround I've thought of is to completely rebuild the ZIP file, which isn't efficient.
Re: Incorrect internal timestamps in OOo file format?
I agree: there's something fishy going on here, but I'm not entirely sure what.
It should 'just work' to unpack an ODF archive, update a file, and then have zip -f ("freshen") update only files that have more recent times. That doesn't work for me either, doing it manually.
According to the zip man page, the local time zone is taken into account, and this should work. I'm not sure what's going on that it doesn't.
In any case, I'm not so sure that it's OOo's fault, but it wouldn't hurt to file an issue. It's in everybody's interest to have this working.
Whoops, hold on, here's your bug: Issue 18194: Package component uses UTC time for internal streams..
You can register there and add your vote (up to two) or comment.
As a workaround, can you set the "TZ" environment variable for ant and/or zip? E.g. this works from the command line:
It should 'just work' to unpack an ODF archive, update a file, and then have zip -f ("freshen") update only files that have more recent times. That doesn't work for me either, doing it manually.
According to the zip man page, the local time zone is taken into account, and this should work. I'm not sure what's going on that it doesn't.
In any case, I'm not so sure that it's OOo's fault, but it wouldn't hurt to file an issue. It's in everybody's interest to have this working.
Whoops, hold on, here's your bug: Issue 18194: Package component uses UTC time for internal streams..
You can register there and add your vote (up to two) or comment.
As a workaround, can you set the "TZ" environment variable for ant and/or zip? E.g. this works from the command line:
$ date Mon Apr 14 09:32:00 EDT 2008 $ ls -l r2test.ods -rw-rw-r-- 1 jes jes 15534 2008-04-14 09:31 r2test.ods $ unzip -l r2test.ods content.xml Archive: r2test.ods Length Date Time Name -------- ---- ---- ---- 11032 04-14-08 13:31 content.xml -------- ------- 11032 1 file $ unzip -o r2test.ods content.xml && ls -l content.xml Archive: r2test.ods inflating: content.xml -rw-rw-r-- 1 jes jes 11032 2008-04-14 13:31 content.xml $ touch content.xml && ls -l content.xml -rw-rw-r-- 1 jes jes 11032 2008-04-14 09:32 content.xml $ zip -f r2test.ods ...FAIL! $ TZ=UTC zip -f r2test.ods freshening: content.xml (deflated 83%)
AOO4/LO5 • Linux • Fedora 23