i am using salesforce soap api and user getUpdated() method for retrieving updated data but it gives data which is not in timestamp which i gives in method.
$startDate = "2013-09-04 20:51:36"; and
$endDate = "2013-09-05 20:51:36";
Result is
$result = getUpdated("contact", strtotime($startDate), strtotime($endDate)));
but $result also contain data which is having lastModifiedDate="2013-08-19 02:50:00";
what is the reason for this?
there is any mistake in startdate and enddate?
or there is some another way to do this?
The start & end dates are rounded off to minutes (IIRC, down for start & up for end), so the actual date range is slightly larger than the one you specified in this case.
Presumably there's also some TZ offseting going on, which can also account for some of the difference your're seeing (the date/times in the SOAP message typically have the TZ offset in them, so seeing the actual raw dates going back and forth would also help you).
Related
I can't find a way of getting a date from Azure Search using only the date.
The dates in the index are like: "2019-10-15T18:00:00Z","2019-10-22T18:00:00Z","2019-10-29T18:00:00Z"
If I try StartDate/any(s: s eq 2019-10-15T18:00:00Z) I get results
But with StartDate/any(s: s eq 2019-10-15) nothing comes up
I have tried usin the date OData function like so: StartDate/any(s: date(s) eq 2019-10-15) but I get an error 'Function 'date' is not supported'.
Is there any way to get dates without using the time part?
The use of date literals in filters in Azure Search will no longer be supported starting in api-version 2019-05-06-Preview. This was an "accidental feature" that we never intended to support. The reason you don't get any results is because the implicit conversion from Edm.Date to Edm.DateTimeOffset assumes a time of midnight UTC, whereas the dates in your index are 6 PM UTC.
We recommend explicitly providing the time and offset (or Z for UTC) in filters to avoid this problem.
If you want Azure Search to natively support fields and filters of type Edm.Date, please vote for this User Voice suggestion.
Date and time values represented in the OData V4 format: yyyy-MM-ddTHH:mm:ss.fffZ or yyyy-MM-ddTHH:mm:ss.fff[+|-]HH:mm. Precision of DateTimeOffset fields is limited to milliseconds. If you upload DateTimeOffset values with sub-millisecond precision, the value returned will be rounded up to milliseconds.
When you upload DateTimeOffset values with time zone information to your index, Azure Search normalizes these values to UTC.
Refer to supported data types in Azure search.
What is the best way to add an expiry date in CakePHP?
I've got an "expiry date" column in my database, I want to add 1 month to the current date, and store this. At the moment, I'm just using strings and plain PHP date functions to create a new date string to save:
$date = date("Y-m-d");
$date = strtotime(date("Y-m-d", strtotime($date)) . " +31 days");
$this->data['Access']['expires'] = $date;
Is there a "more CakePHP" way or efficient/performance wise?
Performance wise we're most probably talking about micro optimizations at best, so that probably shouldn't be your main concern. However, all the back and forth that you're doing there doesn't make much sense, a single call to strtotime() is all you need, ie
$this->data['Access']['expires'] = strtotime('+31 days');
This will result in a timestamp of "now + 31 days".
The Cake-ish way would be to use the CakeTime class, for example CakeTime::fromString(), like
App::uses('CakeTime', 'Utility');
$this->data['Access']['expires'] = CakeTime::fromString('+31 days');
When passing a string (it also accepts integers and \DateTime instances), this is basically just a wrapper for strtotime(), and an additional mechanism that incorporates the timezone set for your application, so while this will be a little bit slower of course, it might still be wise to use it.
See also
Cookbook > Core Libraries > Utilities > CakeTime
Better that adding 31 days is better to use 1 months this will add 30 or 31 days depending on which month will be the current date
$dateAfterOneMonth = date('Y-m-d H:i:s', CakeTime::fromString('+1 months'))
I have an issue with getting dates back in the right timezone.
Firs at all in the local machine, everything works fine but not in the server: the server is hosted in USA and the clients mostly are in Australia.
So a date is sent from angular app("12/23/2015 11:00:00 AM") to the server, the server store a date as utc in the database, until this point everything is working(I checked and the date is stored in the right utc)
book.StartDateTime = TimeZoneInfo.ConvertTimeToUtc(DateTime.SpecifyKind(book.StartDateTime.Value, DateTimeKind.Unspecified), ToolsHelper.OlsonTimeZoneToTimeZoneInfo(locationDetails.TimeZone)); // book.CreatedDate.Value.ToUniversalTime();
The issue is:
When a client request some dates stored in the database. The date stored in the database is return back to the client like this:
bookview.StartDateTime = TimeZoneInfo.ConvertTimeFromUtc(DateTime.SpecifyKind(bookli.StartDateTime.Value, DateTimeKind.Utc), ToolsHelper.OlsonTimeZoneToTimeZoneInfo(deCompany.TimeZone));
I checked and at this point the date is "12/23/2015 11:00:00 AM" -> the conversion is right in the server(in the server side I put a log),
But in the angular is shown as "12/23/2015 10:00:00 PM"
So apparently the issue is when the date is transferred by the api to the client, maybe when is converted to JSON
I have tried different ways nothing work, I have removed "DateTime.SpecifyKind", I convert the date to string then back to datetime format and nothing seems to work.
What could I do?
A few things:
Your example is not complete, so I can only speculate on some areas. It would be better to show both sides, including how you load and parse the data in Angular, and what the data looks like over the wire.
You shouldn't be sending dates back and forth in a locale-specific format like "12/23/2015 11:00:00 AM". You might use those in your UI, but they're not appropriate over the wire (in your JSON). Instead, you should be using ISO8601/RFC3339, such as "2015-12-23T11:00:00Z". (You probably are already doing this if you're using WebAPI.)
A DateTime object when serialized to ISO8601 format is coupled with the associated DateTimeKind in the Kind property.
If the Kind is Utc, then the ISO8601 string will end with a Z.
If the Kind is Local, then the ISO8601 string will end with the machine-local offset for that timestamp, such as -08:00.
If the Kind is Unspecified, then the ISO8601 string will not have either Z or offset - which means that it cannot unambiguously represent a specific moment in time.
This is ultimately the cause of the error. You're converting the DateTime to another time zone, which leaves it with Unspecified kind, which then gets serialized without an offset - so on the client side that gets interpreted (probably) in the local time zone of the browser.
A better approach is to use DateTimeOffset instead of DateTime. Then you don't have to worry about Kind, and the offset is always present. If you change your bookview.StartDateTime to a DateTimeOffset type, you can do something like this to fix the problem:
DateTimeOffset dto = new DateTimeOffset(bookli.StartDateTime.Value, TimeSpan.Zero);
bookView.StartDTO = TimeZoneInfo.ConvertTime(dto, ToolsHelper.OlsonTimeZoneToTimeZoneInfo(deCompany.TimeZone));
That will ensure that the offset gets persisted in the data.
On the client side, pay careful attention to how the ISO string gets parsed. if it's loaded into a Date object, then it will indeed be converted to the client's time zone. Instead, you might take a look at moment.js for client-side time formatting. In particular, use moment.parseZone to keep the value in the same offset that it was presented. For example:
var s = moment.parseZone("2015-12-31T11:00:00+00:00").format("L LT"); // "12/31/2015 11:00 AM"
In commented code, you also showed a call to DateTime.ToUniversalTime - be very careful with that. If the source kind is Unspecified, it is treated as Local. Therefore, the local time zone of the computer is reflected in the converted value. It's better to avoid ToUniversalTime and ToLocalTime entirely. Use only the conversion methods on TimeZoneInfo.
ToolsHelper.OlsonTimeZoneToTimeZoneInfo isn't something we know about either. But I'll assume it does a CLDR mapping similar to this one. However, if you're working with Olson time zones anyway, the better approach would be to not use TimeZoneInfo at all. Instead, use Noda Time, with it's native support for tzdb time zones.
I have a report which takes timezone as input parameter, picks date from a table and converts this date to the user selected time zone.
User can select timezones from a dropdown which contains both US and European timezones.
When I select the European timezones, I see #Error in the date cell in the report.
I have no clue what so ever about reports and I need to fix this error in the inherited report.
The conversion is done by a little VB script embedded in the report.
Shared Function ConvertTimeZone(ByVal systemDate As Date, ByVal timeZoneId As String) As Date
Dim timeZoneInfo As TimeZoneInfo
timeZoneInfo = timeZoneInfo.FindSystemTimeZoneById(timeZoneId)
Return (timeZoneInfo.ConvertTimeFromUtc(systemDate, timeZoneInfo))
End Function
If EET is passed as timezone id - I see #Error in the date cell.
Could this be because both European and US timezones cant be used together?
Can someone guide me through this issue?
If EET is passed as timezone id - I see #Error in the date cell
That's because "EET" is not a valid time zone identifier. You can see all of the valid identifiers by examining the output from TimeZoneInfo.GetSystemTimeZones(), which returns a collection of TimeZoneInfo objects. Each one has an Id and a DisplayName. The Id is what needs to be passed in your timeZoneId parameter, while the DisplayName can be shown to your end user in the dropdown list. (You probably don't want to use the StandardName or DaylightName properties, unless you have a specific reason to.)
You are probably looking for the identifier "E. Europe Standard Time". Don't get confused by the name, it's the correct identifier covering both Eastern European Time (EET) and Eastern European Summer Time (EEST). The Microsoft time zone database is a bit strange in that way.
You can also see the valid time zones by running tzutil /l on the command line. Each time zone will emit two lines, where the top line is the display name, and the bottom line is the ID.
EDIT
Another suggestion, VB is case insensitive, but you have your variable named timeZoneInfo, which is the same as the class TimeZoneInfo. This would normally work ok, but I see that you have the lower case form on the ConvertTimeFromUtc method, and it should be upper case. Since this is VBScript, you might not be seeing this error until runtime. Try changing the case, or just use a different variable name so you don't get them confused.
Shared Function ConvertTimeZone(ByVal systemDate As Date, ByVal timeZoneId As String) As Date
Dim tzi As TimeZoneInfo
tzi = timeZoneInfo.FindSystemTimeZoneById(timeZoneId)
Return (TimeZoneInfo.ConvertTimeFromUtc(systemDate, tzi))
End Function
Here's another idea you can check if that doesn't fix it. The input systemDate should have come from your data, which should have DateTimeKind.Unspecified when you examine it's .Kind property. If for some reason you are taking it from DateTime.Now instead, then it would have a DateTimeKind.Local, which would through an exception.
If you still get the error, please see if you can find out what exception or error is actually occurring. Check log files, event viewer, etc.
What am I doing wrong in this query?
SELECT * FROM TreatmentPlanDetails
WHERE
accountId = 'ag5zfmRvbW9kZW50d2ViMnIRCxIIQWNjb3VudHMYtcjdAQw' AND
status = 'done' AND
category = 'chirurgia orale' AND
setDoneCalendarEventStartTimestamp >= [timestamp for 6 june 2012] AND
setDoneCalendarEventStartTimestamp <= [timestamp for 11 june 2012] AND
deleteStatus = 'notDeleted'
ORDER BY setDoneCalendarEventStartTimestamp ASC
I am not getting any record and I am sure there are records meeting the where clause conditions. To get the correct records I have to widen the timestamp interval by 1 millisecond. Is it normal? Furthermore, if I modify this query by removing the category filter, I am getting the correct results. This is definitely weird.
I also asked on google groups, but I got no answer. Anyway, for details:
https://groups.google.com/forum/?fromgroups#!searchin/google-appengine/query/google-appengine/ixPIvmhCS3g/d4OP91yTkrEJ
Let's talk specifically about creating timestamps to go into the query. What code are you using to create the timestamp record? Apparently that's important, because fuzzing with it a little bit affects the query. It may be relevant that in the datastore, timestamps are recorded as integers representing posix timestamps with microseconds, i.e. the number of microseconds since 1/1/1970 UTC (not counting leap seconds). It's also relevant that dates (i.e. without a time) are represented as midnight, i.e. the earliest time on that day. But please show us the exact code. (It may also be important to show the actual content of the record that you're attempting to retrieve.)
An aside that is not specific to your question: Entity property names count as part of your storage quota. If this is going to be a huge dataset, you might pay more $$ than you'd like for property names like setDoneCalendarEventStartTimestamp.
Because you write :
if I modify this query by removing the category filter, I am getting
the correct results
this probably means that the category was not indexed at the time you write the matching records to the data store. You have to re-write your records to the data store if you want them added to the newly created index.