Description of problem: Running unzip -l on a zip file shows dates like this: 4633 01-02-2009 16:33 unzip60/BUGS Here in Europe, this date would be interpreted as 1st February 2009, but it is in fact 2nd January 2009 as the next entry will show: 5393 03-31-2007 19:14 unzip60/Contents If there are no unambiguous dates in the zip file, the user may misinterpret the date format. The the date output by unzip should be correct and non ambiguous: either a format chosen by the user or a standard format. Ideally, the date format should be that required by the user: as defined by the LC_TIME environment variable (as "ls" does). If this is not possible, then the date format should at least be unambiguous: eg the ISO date format. This can be achieved by compiling with DATE_FORMAT=DF_YMD I tested this by downloading unzip60.zip, changing these two lines in unix/Makefile: CFLAGS = -O -DDATE_FORMAT=DF_YMD CF_NOOPT = -I. -I$(IZ_BZIP2) -DUNIX -DDATE_FORMAT=DF_YMD $(LOC) and running: cp unix/Makefile . make linux_noasm ("make linux" complained about errors in the assembler code). The modified unzip produces unambiguous dates in the output: 4633 2009-01-02 16:33 unzip60/BUGS 5393 2007-03-31 19:14 unzip60/Contents Version-Release number of selected component (if applicable): unzip-6.0-7.mga4 How reproducible: Every time. Steps to Reproduce: 1. unzip -l any-zip-file 2. See the dates in an ambiguous format. Reproducible: Steps to Reproduce:
Alex may be interested in this one, since he worked on this package recently.
CC: (none) => loginov_alex
Martin, hello, Please test unzip from Cauldron, which was built with libnatspec. I have correct outputs dates: unzip -l IMAP-5020M_update_102012.zip Archive: IMAP-5020M_update_102012.zip Length Date Time Name --------- ---------- ----- ---- 0 2012-11-06 15:34 IMAP-5020M_update_102012/ 15872 2012-04-10 08:31 IMAP-5020M_update_102012/AutoCopyFile.exe 43 2012-04-10 08:31 IMAP-5020M_update_102012/Config.ini
The Cauldron version looks good.
Martin, thank you for testing.
Mageia 4 changed to end-of-life (EOL) status on 2015-09-19. It is is no longer maintained, which means that it will not receive any further security or bug fix updates. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version. Bug Reporter: Thank you for reporting this issue and we are sorry that we weren't able to fix it before Mageia 4's end of life. If you are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. If it's valid in several versions, select the highest and add MGAxTOO in whiteboard for each other valid release. Example: it's valid in cauldron and Mageia 5, set to cauldron and add MGA5TOO. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. If you would like to help fixing bugs in the future, don't hesitate to join the packager team via our mentoring program [1] or join the teams that fit you most [2]. [1] https://wiki.mageia.org/en/Becoming_a_Mageia_Packager [2] http://www.mageia.org/contribute/
Hi, thanks for reporting this bug. We are sorry, but we no longer maintains this version of Mageia. Please upgrade to the latest version and reopen this bug against that version if this bug exists there. As a result we are setting this bug to CLOSED:WONTFIX With according https://bugs.mageia.org/show_bug.cgi?id=13194#c3 this bug is not present in mga5, cauldron, issue is only for mga4, but mga4 is EOL.
Status: NEW => RESOLVEDResolution: (none) => WONTFIX
Alex please stop doing that. That's not what my message says. Closing will happen in one month from now.
Status: RESOLVED => REOPENEDResolution: WONTFIX => (none)
As announced over a month ago, Mageia 4 changed to end-of-life (EOL) status on 2015-09-19. It is is no longer maintained, which means that it will not receive any further security or bug fix updates. This issue may have been fixed in a later Mageia release, so, if you still see it and didn't already do so: please upgrade to Mageia 5 (or, if you read this much later than this is written: make sure you run a currently maintained Mageia version) If you are able to reproduce it against a maintained version of Mageia, you are encouraged to 1. reopen this bug report, by changing the "Status" from "RESOLVED - OLD" to "REOPENED" 2. click on "Version" and change it against that version of Mageia. If you know it's valid in several versions, select the highest and add MGAxTOO in whiteboard for each other valid release. Example: it's valid in cauldron and Mageia 5, set to cauldron and add MGA5TOO. 3. give as much relevant information as possible. If you're not an experienced bug reporter and have some time: please read this page: https://wiki.mageia.org/en/How_to_report_a_bug_properly If you see a similar issue, but are _not_sure_ it is the same, with the same cause, then please file a new bug report and mention this one in it (please include the bug number, too). If you would like to help fixing bugs in the future, don't hesitate to join the packager team via our mentoring program [1] or join the teams that fit you most [2]. [1] https://wiki.mageia.org/en/Becoming_a_Mageia_Packager [2] http://www.mageia.org/contribute/
Status: REOPENED => RESOLVEDResolution: (none) => OLD
Bug is fixed in both Mageia 4 and 5: unzip -l now produces dates in the (unambiguous) ISO format yyyy-mm-dd hh:mm
Resolution: OLD => FIXED