LotusScript Unix Timestamp Method
Just recently I've been doing more and more work with SQL and Domino. Sometimes trying to get them to live in unity. This is what I am trying to do now as I work on a Domino With Google Gears proof of concept.
While working with both a SQL backend and a Domino backend one recurring issue I'm finding is that of date-time formats and getting one to understand the other.
If you create a SQL table to hold details of a set of Notes document and you want to add a "Created Date" column then you'll probably get stuck converting Notes' dates to SQL dates.
LotusScript Function
The easiest way I've found is to get them both to talk to each other in "Unix time" -- that is, the number of seconds elapsed since midnight on 1st Jan 1970.
To do this I created a little LotusScript function to work out the Unix time for a given variant of type Date, such as a document's LastModified property. Here's the function:
Function getTimeStamp(dt As Variant) As Long Dim dtEpoch As New NotesDateTime("1/1/1970 00:00:00") Dim dtTemp As New NotesDateTime(Now) dtTemp.LSLocalTime = dt getTimeStamp = dtTemp.TimeDifference(dtEpoch) End Function
Usage:
Msgbox getTimeStamp(doc.LastModified) Msgbox getTimeStamp(Now)
Prints out something like:
1243500324 1243510655
These values can then be stored in a SQL column of type "timestamp" and we can use SQL to convert to any format we like. Hey presto.
Your Thoughts?
Before I wrote the function I only did a cursory check that there isn't a method to get this number from a NotesDateTime already. Hopefully there isn't and I've not publically shamed myself yet again?
A few years ago we had a manager that wrote a database for his lab's in MS Access but the Request System was in Notes. So we made the Notes database the primary using an Agent pushed everything to Access, even the date, then upon completion of the work would pull the test results back into Notes.
With Access we never had any issues with the dates. Sorry :)
Only because it's fresh in my mind from a conversation earlier today... separation of data from logic from display is important. If you use SQL as your data store, you should consider not asking it to also perform too much of the application logic translating the values.
Consider this.
You have a round trip where a date as a time stamp as shown above comes from SQL into the Notes logic engine. You use an LS function to convert the date to the display format and display it to the user. The user edits the friendly version and submits their change. The notes based app logic you have above outputs the timestamp value back to SQL.
So, why, you might ask, not have SQL format the date for you? Dive deeper for a moment into your application logic sitting in Notes. For consistency and better control over your code, you should always have one object responsible for getting data to the UI. That layer, the last stop on the way from SQL before the data gets to the UI, should be the only place the conversion from Timestamp to date occurs. If you do this, all inter-logic operations on the time stamp can work simply with the long value of seconds without the need for date objects or subsequent encoding / decoding of the value.
Keeping it ordered like this, you never have to check yourself when one process in the background is passing or comparing a date with or to another process. You have the time in seconds as your defacto time unit all the way up to the moment the data is pushed to the presentation layer - Gears in this case.
Sounds like a lot of forethought, and it is - but worth the while saved in getting your data coming and going all confused in your logic layer.
Just some thoughts from having built some stupidly complex applications with many layers and having saved myself from certain death by being regimented in the above fashion... painful but nothing worth having is easy to come by, is it?
I agree (I think; not sure I understand) Jerry.
Over the next couple of days it should all become clear why I need a timestamp (replication!). It never gets displayed to the user in this case.