Blame view

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