It's time for 64-bit time

[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?

[Cyllceaux]

+1

[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].

[davido]

+1

[IdeasVacuum]

+1

[Seymour Clufley]

+1

[Demivec]

+1^64

[Dude]

+1

[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

[walbus]

The count down is running
Workarounds and custom tools are no resonable solution....

[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.

[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."

[Mistrel]

Now only 19 years in the future. Time is running out!

http://www.purebasic.fr/english/viewtop ... =3&t=44296

[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.

[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.