Is anyone able to help me convert the lastLogon and lastLogonTimestamp from Active Directory? I am pulling the data with Power Query and for my own user name I and the data is returned like this:
[users.lastLogonTimestamp]=131804496023891686
[users.lastLogon]=131808141012537325
I found this page on Microsoft Docs which states very clearly:
This value is stored as a large integer that represents the number of
100-nanosecond intervals since January 1, 1601 (UTC). A value of zero
means that the last logon time is unknown.
However I am struggling to get a logical result. I have tried converting nanosecond to days, and then adding the days integer to the starting date '1/1/1601' result. Since I have been actively logging in, I should be getting a date result around today's date, '09/10/2018'.
131804496023891686 / 86,400,000,000,000
= 1525.5150002765241435185185185185
_
1525 + '1/1/1601' = Wednesday, March 6, 1605
-- REFERENCES:
1) https://www.calculateme.com/time/nanoseconds/to-days/
2) https://www.timeanddate.com/date/dateadded.html?m1=01&d1=01&y1=1601&type=add&ay=&am=&aw=&ad=1525&rec=
3) https://learn.microsoft.com/en-us/windows/desktop/adschema/a-lastlogon
Okay so this is a DOH! moment... The answer was staring me in the face. I missed the fact that this was represented in 100 nanoseconds not 1 nanosecond.
(131804496023891686*100) / 86,400,000,000,000
152551.50002765241435185185185185
_
152551 + '1/1/1601' = Thursday, September 13, 2018
NOTE: So this result is actually 3 days in the future... not perfect, but what I am really looking for is just "Active accounts in the last 30 days", so I will consider this acceptably accurate.
This article was also helpful-- http://www.selfadsi.org/ads-attributes/user-lastLogonTimestamp.htm.
So, for PowerShell, I put all together as following
(Get-Date '1601-01-01').AddDays([long]::parse($objItem.lastlogon)*100/86400/1000/1000/1000)
Related
I am importing information from an Oracle database on an AIX machine into SQL Server 2008r2. I inherited this process from the previous DBA. The timestamp comes in the following format: 4170180534, which, based on the conversion function in the executable, converts to the following:
417 = year (2017)
018 = days since beginning of year (018 converts to Jan 18)
0534 = time HH:mm
I need to provide maintenance on the conversion function (the previous DBA retired in 2016, so the date conversion function only works through the end of 2016).
Can anyone tell me exactly what this timestamp format is? I assume the '4' stands for the century, but it would be nice to know for sure what the first digit of the value actually is.
4should stand for weeks since start of year
format for that would be
(weeks since 1st jan, 2last digits of year, days since 1st jan, hours, minutes)
WW IY DDD HH MI
I am using server time for one of my process. For that I am taking date and time using postgresql. The time format I want is 2 digit day,month,hour,minute,second and 4 digit year (eg: 05/01/2015 16:05:30). I am using SELECT to_char(now()::timestamp,'DD/MM/YYYY HH24:MI:SS') I want to make sure that the number of digits for each will be as like I want. Because its very important for my processing. I have refered the following link Link. There it is saying, day of month (01-31) for DD's decription. Is there any possibility to get day as 1 instide of 01
Feel safe.
The table ad your link (http://www.postgresql.org/docs/9.4/static/functions-formatting.html#FUNCTIONS-FORMATTING-DATETIME-TABLE)
is right.
Numbers in date converted with to_char, are 0 padded.
Is there any possibility to get day as 1 instide of 01
You can use regular expression to remove leading 0:
select regexp_replace(to_char(now()::timestamp,'DD/MM/YYYY HH24:MI:SS'), '^0(\d)', '\1', 'g');
DATEDIFF(datepart,FromDate , Todate)
SELECT DATEDIFF(dayofyear,'2008-08-07','2008-08-09') AS DiffDate
Result = 2 days
which date sql sever is exclude while calculating difference FromDate or Today ?
Why it not be 3 days for 7,8 and 9 ?
For simplicity, for yourself, you could remember that DATEDIFF views the range as including the "from" date and excluding the "to" date. So, in your case, only the 7th and the 8th are counted.
Formally, however, the logic is described to be this:
Returns the count (signed integer) of the specified datepart boundaries crossed between the specified startdate and enddate.
How many DAYOFYEAR boundaries are there between 2008-08-07 and 2008-08-09?
2008-08-07 -> 2008-08-08
2008-08-08 -> 2008-08-09
Two, as it happens. Hence the result you get.
Because 9-7 is 2 in most decimal maths systems?
Your are on the 7th. How many days to you have to wait to be on the 9th?
2
Ok, I can't understand this thing.
A customer of mine has a legacy Windows application (to produce invoices) which stores date values as integers.
The problem is that what is represented like '01.01.2002' (value type: date) is indeed stored in SQL Server 2000 as 731217 (column type: integer).
Is it an already known methodology to convert date values into integers (for example - I don't know - in order to make date difference calculations easier?)
By the way, I have to migrate those data into a new application, but for as much I googled about it I can't figure out the algorithm used to apply such conversion.
Can anybody bring some light?
It looks like the number of days since Jan 1st 0000 (although that year doesn't really exists).
Anyway, take a date as a reference like Jan 1st 2000 and look what integer you have for that date (something like 730121).
You then take the difference between the integer you have for a particular date and the one for your reference date and you that number of days to your reference date with the DATEADD function.
DATEADD(day, *difference (eg 731217 - 730121)*, *reference date in proper SQLServer format*)
You can adjust if you're off by a day a two.
I'm writing an application that indexes data for our stores, some of which are open late (8 am - 2 am). We need to be able to search this database quickly -- basically, to run a query to find which stores are open at a given point in time (now, Sunday at 1 am, whatever).
In addition, the open/close times can vary day-by-day -- some stores are closed on Sundays, for example.
The obvious solution to me would be to make a table where I have a row with the store ID, day, open time, and close time. For something like Monday, 8 am - 2 am, that would actually be two rows, one for Monday 0800 - 2400, and one for Tuesday 0000 - 0200.
We have a lot of stores, so the search has to perform well (basically, the data has to be index-friendly), but I'll also have to display this data back out in a human-readable format. With my current solution, that'd look something like this:
Monday: 8:00 - Midnight
Tuesday: Midnight - 2:00 am; 8:00 am - Midnight
I'm just wondering if anybody else has alternative solutions before I jump right to an implementation. Thanks!
When PBS (the US Public Broadcasting System) faced this same problem a couple of years ago, they invented the idea of the "30 hour day" -- Where 00:00 is midnight at the start of the day, 24:00 is midnight at the end of the day, 25:00 is 1am the next day, 30:00 is 6am the next day. That way Mon closing time of 26:00 is 2am Tues morning.
Rather than two records representing a single store's times for a day, it may be more object oriented to think of the "store day" as the object. That way 1 record = 1 store's times for a day. If you want to store the two sets of open/close times, just use four fields in the record instead of two--and adjust your queries appropriately.
Remember that your queries should use a library/api that you write and publish. The library will then deal with the data store and its data layout. No one but your library should be looking at the db directly.
Time zones are very important in this sort of app too. (Hopefully) at some point, the store chain will expand to cover more than one time zone. You'll then need to determine the local time of the query. -- May not the same as the time zone of your server which is handling the queries.
Further thoughts--
I now see that you're standardizing to GMT. Good. You could also use datetime values (vs time values) and standardize to a given week in time. Eg open time is Sun Jan 1, 1995 10am - Mon Jan 2, 1995 2am (using Jan 1, 1995 as a base since it was a Sunday).
Then rationalize your "current time and date" to match the same point in the week of Jan 1, 1995. Then query to find open store days.
HTH,
Larry