I produced a report identifying stale accounts older than 60 days. For this time frame, I figured it is fine to use the LastLogonTimeStamp value from one DC. Even with the 9-14 day accuracy caveat, it serves the purpose.
The problem is, someone identified one account that didn't seem right. LastLogonTimeStamp for this account contained a date in July 2011. The user has not been with the company since 2010.
To resolve the discrepancy, I queried each and every DC for the LastLogon attribute. ALL of them are either Never, or they are in 2010.
I also queried each DC for LastLogonTimeStamp, and they are all identical, reporting the July 2011 date. LastLogonTimeStamp is correct for the vast majority of users, so there isn't an underlying replication issue.
So where on earth is this LastLogonTimeStamp coming from, and how can it be so wrong?
Any ideas?
Thanks much,
Sandra
Note that the LastLogon and LastLogonTimestamp attributes are not updated using the same logon criteria (i.e. logon types). See http://support.microsoft.com/default.aspx?scid=kb;EN-US;939899 which explains specifically why they may be different.
From The LastLogonTimeStamp Attribute – What it was designed for and how it works
The intended purpose of the lastLogontimeStamp attribute to help
identify inactive computer and user accounts. The lastLogon attribute
is not designed to provide real time logon information. With default
settings in place the lastLogontimeStamp will be 9-14 days behind the
current date.
LastLogonTimeStamp is the replicable attribute but this attribute is not updated every time a user successfully logs in. This attribute is updated only when its current value is older than the current time minus the value of the msDS-LogonTimeSyncInterval attribute.
Related
I have an application that uses subscriptions for each member that joins. I'm having some issues with dates and calculations related with it. For example, let say a member joins on 2/10/2020 at 10:00. When the user submit the request to the server to process the subscription (the server is using UTC) the date that is being calculate is 2/10/2020 16:00 (because I'm -6:00 hours from UTC). This scenario is OK at this point, because the date is still the same (no matter the time). But, if we replicate this scenario when the user joins for example 2/10/2020 at 19:00, when the request is received and calculate the date, the result is 2/11/2020 01:00, and that produces an error in the invoice because the billing date of the invoice is wrong (one day after). What is the best way to implement this? I have read a lot of this topic, but most of the pages and questions are related in the other way, server to client, to parse of format dates to display to the user.
I have several questions related with this process.
Should I sent the date for the UI to the API? Or the timezone and
based on that, calculate the date in the API? (since the server have
UTC)
Moment.js library have a way to solve this or should be better with vanilla Javascript using Date?
Is there any HTTP header for the request to handle the time or date?
This really depends on what behavior you want to have. Before you try to fix anything, think through and decide on the exact requirements for what the billing date should be based on.
Is the user's time zone relevant? If so, you'll likely need to know what the user's time zone is. You'll be potentially assigning different dates to different invoices even if they're using the same UTC point in time. Your business might get confused on why some customers have invoice dates before or after the business day.
Or maybe the time zone of your company is more relevant? Many business work that way. All of your invoices will be aligned, but some customers might get confused on why their invoice date is before or after their current date.
Or maybe some customers snap to time zones of nearby offices, in the case of businesses with offices around the world.
Only you and your company can decide this. There are probably other options I'm not thinking through here. It's a business decision, not a technical one.
On your three questions:
That depends on what you decide above.
Libraries are a good idea for simplifying your code, but they're not a hard requirement. You can use the Date API, if you know what you're doing, but you may find libraries easier to work with. Also, Moment is in maintainance mode. For new development, the Moment team recommends you use Luxon instead of Moment. There are other popular modern libraries also, including date-fns and js-Joda.
There's the date header, but that's not going to help you with this.
I am updating an application to use NodaTime to fix many existing time issues with our data and processes.
I will need to resolve timezones from a mobile app that sends IANA timezone names. I will need to support conversions to UTC using custom offsets (i.e. hard coded -04:00). I may or may not need to support Windows timezone names as well.
For all of this, I am wondering if I need additional packages. How do TimeZoneConverter and TimeZoneNames work alongside NodaTime? Are there any other additional packages I should use alongside NodaTime?
Our ultimate goal is to get all data persisted as Utc and convert to/from user time only for display or accepting user input.
You don't need any extra packages for that scenario, as far as I can see.
For IANA IDs, just use DateTimeZoneProviders.Tzdb
For "raw offset" IDs, you can use any time zone provider, asking for an ID of the form "UTC+01:00" etc. (So you'd need to add the "UTC" prefix.)
For Windows zone mapping, you can use TzdbDateTimeZoneSource.Default to get the default TZDB information, then use the WindowsMapping property to get a WindowsZones object you can use for mapping.
TimeZoneConverter may well be simpler to use for the last bullet point, but it's not required. The IANA IDs it provides should work fine with Noda Time.
TimeZoneNames is more about displaying time zone names to users. If you don't need to do that, you probably don't need the package.
Note that persisting all data as UTC may be a really bad idea - it's hard to tell without knowing more about your application. If you only deal with values in the past, or if they're fixed instants in time, that's fine. But if you're allowing users to schedule future events, I'd store the values that the user gave you. Here's an example of why...
Suppose the user says they want to schedule an event for Europe/Paris at 9am on December 1st 2021. If you convert that to UTC now, you'll end up with 2021-12-01T08:00Z, because the current time zone rules say that Paris will be at UTC+1 in December 2021.
However, it's entirely possible that between now and 2021, France will have changed its time zone rules to be on "permanent daylight time", i.e. UTC+2 all year round. At that point, your UTC value of 2021-12-01T08:00Z would correspond to 10am in Paris on the given date - contrary to what the user specified.
It's fine to convert to UTC as well so that you can create a totally ordered view of the data, so long as you retain enough information to perform that conversion again every time there's new time zone data.
As I say, that may not be an issue for you, but it's worth knowing that the "received wisdom" of "Always store everything in UTC" is really not good advice for all scenarios.
Yet another weird story from Domino Designer 9.0.1:
The application in question is set to support German and English; German is set to be both the source and the default langauge.
Over the course of the past few weeks we observed that there are some CustomControls and Xpages whose properties files are multiplying; within something like 12 hours we often see hundreds of multiplied files (currently we have 120 multiplications; earlier this week we had a case with > 1000 multiplied propertiey files!) In package explorer they turn up like this:
As you can see there is something like a docUnid added to the property's file name. Apart from a different time stamp they all are identical internally. In same cases both language versions are multiplied, in this particular case here only the German (= source) version shows that phenomenon.
Another strange fact: this particular custom control hasn't changed for quite a while, and it only contains a single control with a static text attribute, alongside a
Anyone having an idea what could be causing this, and what possible solutions I could try?
Tech facts and some more observations:
Domino Designer 9.0.1 FP6, ExtLib 17; we are working in a team where each one of us is coding in their own local replica, then replicating into the "hub" replica. I can't prove it but I assume that there is a connection between one of us replicating updates and the creation of new prüperty duplicates
EDIT: some more observations: I think I was able to pin it down to the replication between two specific machines; I just ran a sequence of 5 or 6 manually driven replications between both instances, every time without making any changes to the design code on either side. nevertheless every replication reported exactly 1 update and 1 addition, and each time a new property file was added.
So meanwhile I deleted the custom control in question and rebuilt it from scratch under a slightly different name (just to be on the safe side). For now it seems that the application is "behaving" now but I'm sort of sure that this will return sooner or later.
Speak after me: source control and replication do not match.
More details:
The property files get stored as attachments in a design note. That's usually the note with the form. Unless you switch on multi lingual, then each property gets its own note. When different people work on the database these note elements get recreated on build getting the next UNID kind of.
So the right flow for what you try to do: pick your best version of the nsf. Nuke the other replicas. Bind it to version control. Let your peer developer create an nsf from that repository. Sync of design shall only happen via that repository.
While your on it: add Bavarian as language, so your Munich customers can use the app too
All 16 of these venues have same name and same lat/lon.
In this case, their category is private residence, so that helps make a decision as to what to do with them and it turns out to not be a problem, but still, what's going on? Is this something to worry about?
https://foursquare.com/v/puamana-condos/4ce1ef7b70bba1cd8e7574c4
https://foursquare.com/v/puamana-condos/4ce18e8e78ddf04db02cac98
https://foursquare.com/v/puamana-condos/4ce18eb7ffcf3704f4842682
https://foursquare.com/v/puamana-condos/4ce18ebec4f6a35dd2fddb6c
https://foursquare.com/v/puamana-condos/4ce18ec469136dcbb332eae6
https://foursquare.com/v/puamana-condos/4ce18ec678ddf04dd72dac98
https://foursquare.com/v/puamana-condos/4ce18ec77e2e236ac60e911b
https://foursquare.com/v/puamana-condos/4ce18ec8f8cdb1f717549d12
https://foursquare.com/v/puamana-condos/4ce18ec994c3b60c455577ea
https://foursquare.com/v/puamana-condos/4ce18eca825e721ec75c7c45
https://foursquare.com/v/puamana-condos/4ce18ecb3644a093f4c65d9f
https://foursquare.com/v/puamana-condos/4ce18ed9f8cdb1f75e549d12
https://foursquare.com/v/puamana-condos/4ce18ee4ffcf3704fe852682
https://foursquare.com/v/puamana-condos/4ce18ef3db125481d59242ce
https://foursquare.com/v/puamana-condos/4ce18ef9aba88cfa690556d7
https://foursquare.com/v/puamana-condos/4ce1ef4fc4f6a35d2f29de6c
It looks like all these venues were created by a single user on a single day back in December 2010. This was before we implemented more rigorous checking about existing duplicates before creating new venues, so it was probably a side effect of a poor connection / multiple creation attempts. Marking them as dupes and this should be cleaned up soon.
Because they're homes, they don't show up in normal "nearby" queries, which is why our SU community probably hadn't found them till now.
Why is Foursquare Campaign Timeseries viewingUsers and unlockingUsers always returning 0? Thanks. I tried with a simple check-in special and was able to unlock it already and asked a number of friends to view it and check in as well but no luck. Thanks!
I don't think the viewing/unlocking Users stats are updated in realtime just yet, so as long as the data shows up after a day or two, that's the expected behavior. You may want to also try specifying startAt and endAt as part of the request if you care about a particular time range.