Y2038 September 2022

y2038@lists.linaro.org

18 participants
18 discussions

by 大陆出口香港运输，大量� �敏感货，液体� ��口罩，试剂盒，化工品，食� �等

  大陆出口香港运输，大量接敏感货液体，口罩，试剂盒，化工品，食品等  ■  大陆上门提货，运输报关一条龙服务 ■  香港可提供装卸货，拼箱，仓储服务 ■  九龙/新界/港岛派送公司以及仓库 ■  香港机场/仓码头仓入仓服务联系我们联系人：JackMobile ：+86-13642980935 (微信同号）E-mail : wuliu56sales01(a)hotmail.com

4 years

---东南亚专线---越南/泰国/新加坡/马来/印尼/菲律宾/柬埔寨/缅甸门到门

by 东南亚专线 ---越南/泰国/新加坡/马来/印尼/菲� ��宾/柬埔寨/缅� � 门到门

  越南/泰国/新加坡/马来/印尼/菲律宾/柬埔寨/缅甸东南亚专线门到门；  专业操作东南亚物流，跨境电商物流头程；可提供海外仓储，配送，一件代发；帮助企业在进出口物流方面提供方案，节省运输成本，提高运输时效； 1. 越南专线（出口方式：双清包税/正报正清/正报双清）2. 柬埔寨专线（出口方式：双清包税）;3. 泰国专线（出口方式：双清包税；正报正清；正报双清；）4. 新加坡专线（出口方式：双清包税（GST可含可到付）；正报正清；）；海运/空运5. 马来西亚专线（出口方式：双清包税，正报双清）海运/空运；6. 印尼专线（出口方式：双清包税，正报双清）海运/空运；7. 菲律宾专线（出口方式：双清包税，正报双清）海运/空运；8. 缅甸专线（出口方式：双清包税，正报正清）海运/陆运/空运；9. 小包裹空派东南亚（新马泰，印尼，越南）日本，台湾  双清包税到门，可接敏感货，仿牌；欢迎来电咨询联系人: JackMobile: +86-18025948799E-Mail：salesworld008(a)hotmail.com

4 years

FOB深圳盐田/蛇口整柜拖车报关一条龙服务

by FOB深圳盐田/蛇� ��整柜拖车报� �一条龙服务

        深圳盐田、蛇口整柜报关交仓      本公司是集拖车、商检、报关、报检、仓储、码头内装等服务的专业的码头服务公司          东莞到深圳盐田/蛇口整柜,欢迎有柜来电咨询。（珠三角到深圳盐田/蛇口整柜拖车都可以达到）   联系人：杨生                Mobile:13642980935            E-Mail：hkrt56(a)hotmail.com         

4 years

香港吨车/整车运输

by 香港吨车/整车运输

  香港吨车/整车运输 1.中港进出口吨车 3--15吨车2.中港进出口拖车 20--45HQ3.中港冻柜，平板车，吊臂车，危险品车4.代理（买单）报关，代填公路舱单5.香港无缝清关，香港出口清关6.香港派送，本地提货，本地拖车，仓储联系人:  Mr YangMobile: +86-13642980935E-Mail：hkwuliu(a)hotmail.com

4 years

PRODUCT INQUIRY

by KENT CREEK

Dear Sir/Madam, We are writing in to express our business interest in your company’s products. Please send us the information on all products available. It would be appreciated if you can send brochures and price lists for the entire range of products. Thank you in advance, and i look forward to receive the requested details from you. Sincerely, Kent Creek Raymond E Frost & Associates 39510 Paseo Padre Pkwy Fremont, CA 94538 251-225-6117

4 years

进出口报关l78l8858453

by jinchukoubaoguan＠hotmail.com

你好；我司专注：全国各地口岸整柜/拼柜买单报关（高退、包查验、包放行）提供源头产地证、出口许可证、商检、各种清关单证等等欢迎咨询：小占l78l8858453 （微信同号）业务QQ:l5793l329 加以备用期待与您合作、打扰之处敬请谅解

4 years

CONGRATULATIONS.

by Mackenzie Scott

Dear Beneficiary, After signing the Giving Pledge in 2019, I decided I was going to give away at least half of my fortune to charity and towards improving the lives of those in dire need of immediate support as a result of the Covid-19 pandemic. So far I have been able to give out $12 billion USD in donations to charities, schools, churches, businesses and individuals across the globe through The Scott Foundation. I'm currently donating another $4 billion. An online polling was conducted by The Scott Foundation from which your email emerged as one of the lucky winners of $6,850,000.00 USD donation grant from me. You are to contact THE SCOTT FOUNDATION by replying to this email for more information if you're interested in receiving this donation. Congratulations. Yours Sincerely Mackenzie Scott.

4 years

Re: RTC hctosys disabled for 32-bit systems

by Arnd Bergmann

On Thu, Sep 1, 2022, at 1:31 PM, Reinier Kuipers wrote: > > I'm working to fix the y2038 issue for an existing sama5d3-based > product. This involves updating the kernel and glibc to appropriate > versions (5.10 and 2.35.1 respectively) and I got things running up to > a state where, from userspace, both date and hwclock commands have no > issue accepting dates beyond 2038. However, even with the RTC_HCTOSYS > and RTC_HCTOSYS_DEVICE options configured correctly, the RTC driver > fails to initialize the system clock at bootup. > > Some digging in rtc/class.c::rtc_hctosys() indicates that > do_settimeofday64() is deliberately not executed on systems with > BITS_PER_LONG==32 and a second counter higher than INT_MAX. I assumed > that the work on 64-bits timestamps was already fully implemented for > 32-bit systems as well, so my gut feel is that this > BITS_PER_LONG/INT_MAX check has become unnecessary. A test build with > these checks disabled results in correct time initialization at bootup > with, at a glance, no adverse effects. Does anybody here know whether > do_settimeofday64() is robust on 32-bit systems or that the checks > are still required to prevent further breakage? Please see commit b3a5ac42ab18 ("rtc: hctosys: Ensure system time doesn't overflow time_t") and https://github.com/systemd/systemd/issues/1143 for the problem that originally caused this to be added. Removing this check would probably break systemd again for machines that return a post-y2038 time with systemd built on 32-bit time_t. The only reliable fix I can see would be to disable CONFIG_RTC_HCTOSYS_DEVICE. I think this is Alexandre's plan for the long run anyway, but I don't know if there has been any progress in convincing distros to turn it off. Arnd

4 years

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Y2038 September 2022