I’ve searched, no good posts like this.
App runs in the client.
User clicks a button that includes @SetField(“fieldName”;@Now).
Today is 14.Apr.2008
Field gets 19.Apr.2008 (confirmed by checking field in doc properties).
PC date is correct
Time zone and country settings are correct.
Server date is correct.
Log user off, log 2nd user onto same station, execute the same code: Date = 14.Apr.2008.
Log 2nd user off, log 1st user back onto same work station, execute the same code: Date = 14.Apr.2008
WTF???
User was running
ProductCenter (doc management system used mainly for CAD drawings, accessed via web interface).
Oracle Business system (java based web interface)
Outlook
Excel
CaptureEZ (screen capture program)
and Notes.
Does anybody know if anything in the list of stuff he was running could possibly step on @Now?
I’m hearing ‘Twilight Zone’ music right now…is it just me?
TIA if anybody has any ideas.
Doug
Subject: Date for @Now wrong, no it’s right…
This can happen if the user plays with the Windows clock.
Notes has it’s own internal clock that is synchronized with the Windows clock when it loads.
If you open the windows date/clock dialog, and change the date, the PC’s clock is updated immediately. When the user cancels the dialog, the change is rolled back, and the PC’s clock corrected to the current date.
Notes also rolls it’s clock forward if the user clicks on a future date, but will NOT roll it’s clock backwards. I understand that this is because that could really mess up processes like replication that might be running.
So let your users know NOT to use the windows dialog as a Calendar to look up future months. Use the Notes calendar instead.
Subject: RE: Date for @Now wrong, no it’s right…
Graham,
Thanks - very interesting. I’ll see if the user will admit to using the pc clock as a calendar.
Seems odd that anything would latch until after the user commits the change, but hey, it’s software!
Doug
Just heard from the user - that was exactly what he did…