Hi,
I stumbeled upon times like these:
11082012300000 (30:00h)
11012012226000 (22:60h)
Since I rewrote the time parsing routine I want to simply print out the time as it is given in the input file, but obviously it will produce errornous output if there are inputs like these. I get an output error now on the testcluster. I hope these are unintendet, if so could you fix the files Cédric?
Thanks!
No worries, I got around it. ;)
In which file did you find that kind of flights ?
I can't find it in the last scenarios.
I found them when looking through the diffs of the output my submission (timestamp: 1354527957) produced.
The given scenarios:
scenario9/flights.txt:12;New York;11082012130000;Rio;11082012300000;600;France Airlines
scenario8/flights.txt:12;New York;11082012130000;Rio;11082012300000;600;France Airlines
scenario7/flights.txt:12;New York;11082012130000;Rio;11082012300000;600;France Airlines
scenario6/flights.txt:12;New York;11082012130000;Rio;11082012300000;600;France Airlines
The newinput3.zip scenario:
9b72bdf6539d2a5be93354cd54d810415435ac10ede08e8442fe1109cd02971f;MEXICO CITY;11012012202000;GUATEMALA;11012012226000;223.91;GUATEMALA Airlines
b07b02877ee070d1b3a36dafa1ac1106d06b6acba6e17a7b09d43f42069a6a5f;MEXICO CITY;11012012202000;GUATEMALA;11012012226000;268.56;MEXICO Airlines
b07b02877ee070d1b3a36dafa1ac110696945aabc0eb3a427e2af8f8bf3fca4b;GUATEMALA;11012012202000;MEXICO CITY;11012012226000;232.83;MEXICO Airlines
9b72bdf6539d2a5be93354cd54d810415e273fd91fb7a76eae82f774ad16a1e8;GUATEMALA;11012012202000;MEXICO CITY;11012012226000;221.13;GUATEMALA Airlines
ok tanks, I will correct that tomorrow
If you want to support this kind of issue, you can use mktime (like in the given code). This function solve this kind of issue and translate 30h00 to 6h00 the day after
Sure, I could, but it constructs a time_t in local time, which produces wrong results. I spent a whole day trying to figure out why mktime and localtime are not symmetric and in the end I dumped it...
Cedric stated that there will be no tricky inputs because it's not the point of this competition. In my humble opinion, it would be only fair to provide regular inputs for the benchmarks and (maybe) correct the inputs. We also don't use mktime, and there are probably more people with the same problem...
Best regards,
Nenad
It was not his intention, he said he will correct them, at least in the benchmarks ;)
EDIT: Ahh, sorry, I got you wrong. I thought you were complaining that he promised it but did it anyways ^^
Of course. I didn't mean anybody had any false intentions :)
Best regards,
Nenad
I corrected the inputs on the cluster. There shouldn't be any problem with that but anyway I didn't notice any problem of this kind with the results on the cluster.
Hi,
We are writing our own string2time function, too. Can we make any assumptions about the flight times? For example: All times are in a Year between 1970 and 2100? Otherwise such a function will become more complex. And using mktime() is very slow...
Small hint that took me a whole day to figure out:
Use the boost::posix_time, it's much faster and you save yourself the trouble with leap years and stuff.
No time before 1970, no time after 2100 :)