Date() returns different time when run in Windows Service

[swhite]

Hi

I have been testing the Date() function to try to find out why my logs are 5 hours ahead on my Windows 2016 server. I discovered if I use

Code: Select all

    WriteStringN(1,FormatDate("%yyyy.%mm.%dd:%hh:%ii:%ss",Date()))

in a regular Windows application created in PB I get the expected time values. If I use the same code in a windows service the time is 5 hours in the future.

Is this a potential bug?

Simon

[Bisonte]

maybe this is a time zone problem ?

Is your normal Time 5 hours from UTC ?

[swhite]

Hi

I am 4 hours behind UTC time as I am in the Eastern standard time. My logs should say 16:12 now but they actually read 21:12.
However, since it works just fine using a PB generated application I do not think that can be the problem.

Simon

[Sicro]

Can you test, please, if the same problem exists with the Date64 module?
The syntax of the Date64 module commands are the same as the PB-native commands, so you can use the macros at the beginning of your code to automatically replace the native date commands with the date64 module commands:

Code: Select all

IncludeFile "Date64.pbi"

Macro Date(Year=-1, Month=1, Day=1, Hour=0, Minute=0, Second=0)
  Date64::Date64(Year, Month, Day, Hour, Minute, Second)
EndMacro
Macro AddDate(Date, Type, Value) : Date64::AddDate64(Date, Type, Value) : EndMacro
Macro FormatDate(Mask, Date)     : Date64::FormatDate64(Mask, Date)     : EndMacro
Macro ParseDate(Mask, Date)      : Date64::ParseDate64(Mask, Date)      : EndMacro
Macro Year(Date)                 : Date64::Year64(Date)                 : EndMacro
Macro Month(Date)                : Date64::Month64(Date)                : EndMacro
Macro Day(Date)                  : Date64::Day64(Date)                  : EndMacro
Macro Hour(Date)                 : Date64::Hour64(Date)                 : EndMacro
Macro Minute(Date)               : Date64::Minute64(Date)               : EndMacro
Macro Second(Date)               : Date64::Second64(Date)               : EndMacro
Macro DayOfWeek(Date)            : Date64::DayOfWeek64(Date)            : EndMacro
Macro DayOfYear(Date)            : Date64::DayOfYear64(Date)            : EndMacro

[BarryG]

The syntax of the Date64 module commands are the same as the PB-native commands, so you can use the macros at the beginning of your code to automatically replace the native date commands with the date64 module commands

Hi, I was hoping this Date64 module would be a direct drop-in replacement for the native Date commands without me changing anything in my source code, but it causes macro errors if your variable names contain the macro keywords. For example, this fails:

Code: Select all

date$=LCase(LSet(Hex(Date()),8,"0"))

So the user must go through their entire source and search/replace such variable names. Not complaining; just posting this as a heads-up. Cheers!

[BarryG]

Also, the Date64 module doesn't work with the CalendarGadget. Try the below, then click January 20 (or any later date) and it fails. Can it be made to work with CalendarGadget (and I guess the DateGadget too)?

Code: Select all

IncludeFile "Date64.pbi"

Macro Date       : Date64::Date64       : EndMacro
Macro Year       : Date64::Year64       : EndMacro
Macro Month      : Date64::Month64      : EndMacro
Macro Day        : Date64::Day64        : EndMacro 
Macro Hour       : Date64::Hour64       : EndMacro
Macro Minute     : Date64::Minute64     : EndMacro
Macro Second     : Date64::Second64     : EndMacro
Macro DayOfWeek  : Date64::DayOfWeek64  : EndMacro
Macro DayOfYear  : Date64::DayOfYear64  : EndMacro
Macro AddDate    : Date64::AddDate64    : EndMacro
Macro FormatDate : Date64::FormatDate64 : EndMacro
Macro ParseDate  : Date64::ParseDate64  : EndMacro

If OpenWindow(0, 0, 0, 250, 200, "CalendarGadget", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)

  CalendarGadget(0, 10, 10, 230, 180)
  d = Date(2038, 1, 19, 3, 14, 7) ; Maximum date supported by PureBasic.
  SetGadgetState(0, d)
  Debug DayOfYear(d)

  Repeat
    Event = WaitWindowEvent()
    If Event = #PB_Event_Gadget
      d = GetGadgetState(0)
      Debug DayOfYear(d)
    EndIf
  Until Event = #PB_Event_CloseWindow

EndIf

[swhite]

Hi

I will give it a try next week.

Simon

Can you test, please, if the same problem exists with the Date64 module?
The syntax of the Date64 module commands are the same as the PB-native commands, so you can use the macros at the beginning of your code to automatically replace the native date commands with the date64 module commands:

Code: Select all

IncludeFile "Date64.pbi"

Macro Date       : Date64::Date64       : EndMacro
Macro Year       : Date64::Year64       : EndMacro
Macro Month      : Date64::Month64      : EndMacro
Macro Day        : Date64::Day64        : EndMacro  
Macro Hour       : Date64::Hour64       : EndMacro
Macro Minute     : Date64::Minute64     : EndMacro
Macro Second     : Date64::Second64     : EndMacro
Macro DayOfWeek  : Date64::DayOfWeek64  : EndMacro
Macro DayOfYear  : Date64::DayOfYear64  : EndMacro
Macro AddDate    : Date64::AddDate64    : EndMacro
Macro FormatDate : Date64::FormatDate64 : EndMacro
Macro ParseDate  : Date64::ParseDate64  : EndMacro

[Sicro]

I was hoping this Date64 module would be a direct drop-in replacement for the native Date commands without me changing anything in my source code

It doesn't work that easy. The macros replace the native date functions of PB, but if the variables that receive the return values of the new Date64 functions are not of type Quad, then the programmer has to adapt this in his code himself. In addition, the macros only work in the main code. If date functions are also used in modules, they are not replaced there. To do this, the macros have to be inserted additionally inside each module at the beginning.

but it causes macro errors if your variable names contain the macro keywords.

That's one reason why variables shouldn't preferably have the same name as functions. I improved the macros in my previous post.

Also, the Date64 module doesn't work with the CalendarGadget. Try the below, then click January 20 (or any later date) and it fails. Can it be made to work with CalendarGadget (and I guess the DateGadget too)?

The Date64 module does not currently provide a 64 version of the SetGadgetState() and GetGadgetState() functions. This is on my ToDo list (in the best case for all OS). I saw that you got an alternative solution code in the other forum thread. Maybe this is enough for you.

[Kuron]

Hi

I am 4 hours behind UTC time as I am in the Eastern standard time.

Eastern Standard Time (EST) is 5 hours behind UTC. You are NOT in Eastern Standard Time right now. This time of year you are in Eastern Daylight Time (EDT) which is 4 hours behind UTC.

[BarryG]

The Date64 module does not currently provide a 64 version of the SetGadgetState() and GetGadgetState() functions. This is on my ToDo list (in the best case for all OS). I saw that you got an alternative solution code in the other forum thread. Maybe this is enough for you.

Hi Sicro, no, the other solution didn't work out for me, so I'd love to see your module updated for SetGadgetState and GetGadgetState. Thank you.

[kenmo]

Eastern Standard Time (EST) is 5 hours behind UTC. You are NOT in Eastern Standard Time right now. This time of year you are in Eastern Daylight Time (EDT) which is 4 hours behind UTC.

Correct, small detail but important.


If you're writing a program for a server, you may want to handle all times as UTC, and convert to local time when displaying to the user.

Code: Select all

ImportC ""
  time.i(*second = #Null)
EndImport

Procedure.i UTCtoLocal(UTCTime.i)
  ProcedureReturn UTCTime + (Date() - time())
EndProcedure

Debug FormatDate("UTC Time:  %yyyy-%mm-%dd  %hh:%ii", time())
Debug FormatDate("Local Time:  %yyyy-%mm-%dd  %hh:%ii", UTCtoLocal(time()))
Debug FormatDate("Verify:  %yyyy-%mm-%dd  %hh:%ii", Date())

[swhite]

Hi

The comment about Day Light Savings time is correct.

So my guess now is that the Date() function returns the UTC time zone without adjusting for Day Light Savings time when called from a Windows Service. I can easily adjust for that.

Simon

[Kuron]

If you're writing a program for a server, you may want to handle all times as UTC, and convert to local time when displaying to the user.

+1