year2038

64-bit time_t in Linux Kernel

由 ￡可爱￡侵袭症＋ 提交于 2021-01-28 06:12:05
问题 I have compiled kernel 3.19.1 but still have a problem with time_t . Just a simple program with cout << sizeof (time_t); gives size of 4 bytes, not 8 bytes as was my intention. Should I switch on a particular option during make menuconfig? 回答1: Currently time_t is just long in kernel: see __kernel_time_t type definition. So if long type on your CPU is 32-bit long, time_t also is 32-bit long. Basically, if you have 32-bit CPU -- long type on your system is also 32-bit long. If you have 64-bit

PHP DateTime setTimezone 2038

由 妖精的绣舞 提交于 2020-01-02 15:02:44
问题 I convert all dates with DateTime (from UTC to Europe/Vienna) in my project. Now I have dates with above 2038, and cannot get the correct time. Example Code: $met = new DateTimeZone('Europe/Vienna'); $utc = new DateTimeZone('UTC'); $date = new DateTime('2043-08-04 08:00:00', $utc); $date->setTimezone($met); echo $date->format('Y-m-d H:i:s'); // Output is: 2043-08-04 09:00:00 instead of 2043-08-04 10:00:00 Between 2043-03-29 and 2043-10-25 there is to calculate +2 hours from UTC, because of

PHP DateTime setTimezone 2038

由 回眸只為那壹抹淺笑 提交于 2020-01-02 15:02:11
问题 I convert all dates with DateTime (from UTC to Europe/Vienna) in my project. Now I have dates with above 2038, and cannot get the correct time. Example Code: $met = new DateTimeZone('Europe/Vienna'); $utc = new DateTimeZone('UTC'); $date = new DateTime('2043-08-04 08:00:00', $utc); $date->setTimezone($met); echo $date->format('Y-m-d H:i:s'); // Output is: 2043-08-04 09:00:00 instead of 2043-08-04 10:00:00 Between 2043-03-29 and 2043-10-25 there is to calculate +2 hours from UTC, because of

Correct way to store MySQL date after year 2037

由 一世执手 提交于 2019-12-22 10:00:00
问题 I am trying to store in MySQL a date() field a successive date to the year 2037 . For example: 2065-12-01 Problem is that the field is returning: 1969-12-31 What is the correct way to record these values on DB? Should I use VARCHAR ? I compute the date field's value like this: $future_date = date('Y-m-d', strtotime("+$number_years_to_add years")); 回答1: You probably use a timestamp field to store the dates and not a datetime field. See mysql documentation on datetime data types, specifically:

Why std::chrono::time_point is not large enough to store struct timespec?

由 主宰稳场 提交于 2019-12-22 04:03:46
问题 I'm trying the recent std::chrono api and I found that on 64 bit Linux architecture and gcc compiler the time_point and duration classes are not able to handle the maximum time range of the operating system at the maximum resolution (nanoseconds). In fact it seems the storage for these classes is a 64bit integral type, compared to timespec and timeval which are internally using two 64 bit integers, one for seconds and one for nanoseconds: #include <iostream> #include <chrono> #include

Why should a Java programmer care about year 2038 bug?

由 可紊 提交于 2019-12-18 03:58:17
问题 Year 2038 Bug is all over the web, But this seems to be a unix issue. How will this affect java Date ? 回答1: What makes you think it does? Java's Date class stores a 64-bit long (not 32-bit, as with Y2K38). It also stores milliseconds, which decreases the range, but only slightly (equivalent of ~10 bits). In Java, we have the year 292278994 bug. 回答2: I don't believe it will impact the Java Date class as for as the programmer is concerned. It's already using 64-bit values. I can see it being a

Accessing dates in PHP beyond 2038

由 社会主义新天地 提交于 2019-12-17 02:31:49
问题 I am of of the understanding that due to the nature that PHP represents dates using milliseconds, you cannot represent dates past 2038. I have a problem where I want to calculate dates far in the future. Thousands of years away. Obviously I cannot use the php date function to represent this date because of the limit, however, I have something on my side... All I want to do is store the year, month and day. I do not care for the hour, minute, seconds and milliseconds. Am I correct in thinking

Converting timestamps larger than maxint into datetime objects

由 元气小坏坏 提交于 2019-12-10 16:46:38
问题 I have some code for converting some timestamps stored as strings into datetime objects and noticed today exceptions when it converts dates with an int timestamp value greater than the max int. datetime.datetime.fromtimestamp(2147570047) for example gives me ValueError: timestamp out of range for platform time_t How can I get around this problem? assuming that I want to stay on 32-bit python (running 2.7.2) I noticed I can convert the max int into the datetime object then add on any extra

time(); after 2038?

由 99封情书 提交于 2019-12-10 13:06:47
问题 Will the php function time(); be functional after the year 2038? 回答1: Of course, when the time comes PHP 42.1.3 will natively support 64-bit integers. 回答2: Yes, it should be. But let me run that code in my VirtuaBox and changed the date as well in there. you know it could be fun to try it out :) 来源： https://stackoverflow.com/questions/5826219/time-after-2038

PHP DateTime setTimezone 2038

由 丶灬走出姿态 提交于 2019-12-06 09:34:49
I convert all dates with DateTime (from UTC to Europe/Vienna) in my project. Now I have dates with above 2038, and cannot get the correct time. Example Code: $met = new DateTimeZone('Europe/Vienna'); $utc = new DateTimeZone('UTC'); $date = new DateTime('2043-08-04 08:00:00', $utc); $date->setTimezone($met); echo $date->format('Y-m-d H:i:s'); // Output is: 2043-08-04 09:00:00 instead of 2043-08-04 10:00:00 Between 2043-03-29 and 2043-10-25 there is to calculate +2 hours from UTC, because of "summertime". If I change 2043-08-04 08:00:00 to 2037-08-04 08:00:00 I get the correct time. I know it is
订阅 year2038