Page 1 of 2
It's time for 64-bit time
Posted: Mon Apr 16, 2018 4:39 pm
by kpeters58
Apparently the Date-Gadgets (and I suspect, the entire code base beneath them) are based on the Unix 32 bit time model, as every attempt of setting them to a time outside of that range (1970 - 2038) demonstrates their uselessness in real-world applications (a big one being used for Date of Birth) by resulting in nonsense dates being displayed.
In this day and age, with all operating systems that matter commercially having switched to 64 bit time years ago (at least in their 64-bit architecture incarnations), this strikes me as odd, to say the least.
Lastly, MacOS has been exclusively 64 bit entirely since 2011 (OS X Lion); Windows licenses sold since 2015 have been 95% (and climbing) 64 bit and Linux just about the same - so why does PB still come with libraries based on the dawn of Unix code?
Re: It's time for 64-bit time
Posted: Mon Apr 16, 2018 4:51 pm
by Cyllceaux
+1
Re: It's time for 64-bit time
Posted: Mon Apr 16, 2018 4:55 pm
by kenmo
+1
I don't use the DateGadget much, but I use the Date library all the time.
I wish the date functions were 64-bit, even on the 32-bit compiler, like FileSize() [which always returns a quad to support large files].
Re: It's time for 64-bit time
Posted: Mon Apr 16, 2018 6:32 pm
by davido
+1
Re: It's time for 64-bit time
Posted: Mon Apr 16, 2018 7:32 pm
by IdeasVacuum
+1
Re: It's time for 64-bit time
Posted: Mon Apr 16, 2018 9:21 pm
by Seymour Clufley
+1
Re: It's time for 64-bit time
Posted: Mon Apr 16, 2018 10:38 pm
by Demivec
+1^64

Re: It's time for 64-bit time
Posted: Mon Apr 16, 2018 11:16 pm
by Dude
+1
Re: It's time for 64-bit time
Posted: Tue Apr 17, 2018 8:22 am
by RSBasic
+1
Workaround for Windows until it is available in PB:
Code: Select all
EnableExplicit
Procedure WinCallback(hWnd, uMsg, wParam, lParam)
Protected *NMHDR.NMHDR
Protected SYSTEMTIME.SYSTEMTIME
Select uMsg
Case #WM_NOTIFY
*NMHDR = lParam
Select *NMHDR\hwndFrom
Case GadgetID(1)
Select *NMHDR\code
Case #DTN_DATETIMECHANGE
SendMessage_(GadgetID(1), #MCM_GETCURSEL, 0, SYSTEMTIME)
Debug Str(SYSTEMTIME\wDay) + "." + Str(SYSTEMTIME\wMonth) + "." + Str(SYSTEMTIME\wYear)
EndSelect
EndSelect
EndSelect
ProcedureReturn #PB_ProcessPureBasicEvents
EndProcedure
If OpenWindow(0, 0, 0, 500, 400, "Window", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
DateGadget(1, 10, 10, 100, 20)
SetWindowCallback(@WinCallback())
Repeat
Select WaitWindowEvent()
Case #PB_Event_CloseWindow
End
EndSelect
ForEver
EndIf
Re: It's time for 64-bit time
Posted: Tue Apr 17, 2018 10:13 am
by walbus
The count down is running
Workarounds and custom tools are no resonable solution....
Re: It's time for 64-bit time
Posted: Tue Apr 17, 2018 10:23 am
by RSBasic
Yes, you're right, but if you want an immediate solution and don't want to wait? Nobody can say when this wish will be realized. In a month or five years?
For me, this is a solution that I use because I cannot do without this function. But everyone can decide whether he/she wants to wait.
Re: It's time for 64-bit time
Posted: Tue Apr 17, 2018 10:28 am
by walbus
It's right what you say, but people don't like the lack of functionality
Well-functioning software is often used for a very long time in companies.
Gorbachev once said, "Life punishes those who are late."
Re: It's time for 64-bit time
Posted: Wed Apr 18, 2018 5:30 am
by Mistrel
Now only 19 years in the future. Time is running out!
http://www.purebasic.fr/english/viewtop ... =3&t=44296
Re: It's time for 64-bit time
Posted: Wed Apr 18, 2018 8:08 am
by walbus
It's very simple
It's been discussed for years.
In terms of market strategy, it is more than important to remove every point of criticism,
whether this is relevant at the moment or not is irrelevant
But I don't primarily care
In my own software, I would have fixed that a long time ago, just to end the constant discussion about it.
Re: It's time for 64-bit time
Posted: Wed Apr 18, 2018 9:23 am
by Marc56us
+1 for 64-bit time
but...
The main problem is how to ensure compatibility with old programs?
All date functions use the number of seconds since 1970/01/01
So how to set an earlier date and stay compatible?
Use negative values?
Change the initial date? (so it would take another library for the old programs to still work)
If it was simple Fred would have done it a long time ago.