I understand that [24:00:00] is an invalid time and I wonder how I can specify midnight.I do not want to use [00:00:00] of the next day because it must be this day and not the next one (categories in view, embedded single category, agent selecting document of one day etc etc).
I do not want to use 23:59:59 first because I do no dare to tell user they have to digit that and secondarily because I want 3600 seconds from 23:00:00 to midnight and not 3599.
Any help before I start messing around ?
Subject: Midnight
First, please read this: Working with Date/Time Values in Lotus Notes.
If you still have a problem, please explain in greater detail what you’re trying to do. You’re writing times in square brackets like they are part of a formula, but then you’re talking about asking users to key in the values.
If users are entering values, their workstation’s preferences will govern how they format their times. 12:00:00 AM is the usual way to signify midnight. Usually, however, if you’re categorizing items by date, you want to avoid having a time stored along with the date, midnight or otherwise.
Subject: Midnight in 24 hours clock (ISO 8601)
I still have problems :-)I try to explain in better detail, as suggested.
I have documents to record events and the form has a date only field and a separate time only field.
We do not have problem with time zone because the application is used locally only by a dozen people.
We use the 24 hours notation 24-hour clock - Wikipedia
In this system the 24:00:00 is used to represent the end of the day while 00:00:00 is used for the beginning of the day.
Yesterday 24:00:00 is the same *moment" as today 00:00:00.
The user needs to record a document showing today midnight (event being, i.e. “I finished my shift and went home”).
He needs the date to be today and the time to be 24:00:00
I haven’t found a way and it’s actually documented that the highest value for Lotus time is 23:59:59
The only way is to record the document as “tomorrow” at 00:00:00 but it’s a pain because it’s categorized among tomorrow events instead of today.
They should workaround recording today at 23:59:59 but it’s very poor solution because leads to wrong calculation of elapsed time between two events. It’s not pretty to see too :-))