Orange Pi5 kernel

^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  1) // SPDX-License-Identifier: GPL-2.0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  2) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  3)  *  linux/fs/isofs/util.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  4)  */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  5) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  6) #include <linux/time.h>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  7) #include "isofs.h"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  8) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  9) /* 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10)  * We have to convert from a MM/DD/YY format to the Unix ctime format.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11)  * We have to take into account leap years and all of that good stuff.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12)  * Unfortunately, the kernel does not have the information on hand to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13)  * take into account daylight savings time, but it shouldn't matter.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14)  * The time stored should be localtime (with or without DST in effect),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15)  * and the timezone offset should hold the offset required to get back
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16)  * to GMT.  Thus  we should always be correct.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17)  */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) int iso_date(u8 *p, int flag)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) 	int year, month, day, hour, minute, second, tz;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) 	int crtime;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) 	year = p[0];
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) 	month = p[1];
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) 	day = p[2];
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) 	hour = p[3];
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) 	minute = p[4];
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) 	second = p[5];
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) 	if (flag == 0) tz = p[6]; /* High sierra has no time zone */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) 	else tz = 0;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) 	
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) 	if (year < 0) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) 		crtime = 0;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) 	} else {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) 		crtime = mktime64(year+1900, month, day, hour, minute, second);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) 		/* sign extend */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) 		if (tz & 0x80)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) 			tz |= (-1 << 8);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) 		
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) 		/* 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) 		 * The timezone offset is unreliable on some disks,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) 		 * so we make a sanity check.  In no case is it ever
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) 		 * more than 13 hours from GMT, which is 52*15min.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) 		 * The time is always stored in localtime with the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) 		 * timezone offset being what get added to GMT to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) 		 * get to localtime.  Thus we need to subtract the offset
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) 		 * to get to true GMT, which is what we store the time
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) 		 * as internally.  On the local system, the user may set
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) 		 * their timezone any way they wish, of course, so GMT
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) 		 * gets converted back to localtime on the receiving
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) 		 * system.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) 		 *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) 		 * NOTE: mkisofs in versions prior to mkisofs-1.10 had
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) 		 * the sign wrong on the timezone offset.  This has now
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) 		 * been corrected there too, but if you are getting screwy
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) 		 * results this may be the explanation.  If enough people
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) 		 * complain, a user configuration option could be added
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) 		 * to add the timezone offset in with the wrong sign
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) 		 * for 'compatibility' with older discs, but I cannot see how
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) 		 * it will matter that much.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) 		 *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) 		 * Thanks to kuhlmav@elec.canterbury.ac.nz (Volker Kuhlmann)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) 		 * for pointing out the sign error.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) 		 */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) 		if (-52 <= tz && tz <= 52)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) 			crtime -= tz * 15 * 60;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) 	}
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) 	return crtime;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) }