I am using IBM provided sample program amqsevt to monitor MQ event queues and parse the messages. But I notice that by default the event creation time is represented in GMT time. I would like to get it converted to System local time. Is there a way to accomplish this?
**** Message #1 (120 Bytes) on Queue SYSTEM.ADMIN.CHANNEL.EVENT ****
Event Type : Channel Event [46]
Reason : Channel Stopped By User [2279]
Event created : 2018/09/04 20:17:39.48 GMT
The source for the sample can be found on Linux with MQ installed in /opt/mqm at /opt/mqm/samp/amqsevta.c.
In the MQMD (Message Descriptor) of every message there is a PutDate and PutTime field that is always stored in GMT and are each simple 8 digit strings for example:
PutDate: 20180904 (YYYYMMDD)
PutTime: 20173948 (HHMMSSSS)
In the sample program it just converts that to the displayed format of 2018/09/04 20:17:39.48 and appends GMT to the end since it knows this is always in GMT.
/**********************************************************/
/* Timestamp is read from the MQMD - it is always in GMT */
/* regardless of local timezone. Do not want to try to */
/* convert it, because this machine may be a client in a */
/* different timezone than the server generating the */
/* event. So stick to GMT (or UCT if you prefer). */
/**********************************************************/
sprintf(valbuf,"%4.4s/%2.2s/%2.2s %2.2s:%2.2s:%2.2s.%2.2s GMT",
&pMsgDesc->PutDate[0],
&pMsgDesc->PutDate[4],
&pMsgDesc->PutDate[6],
&pMsgDesc->PutTime[0],
&pMsgDesc->PutTime[2],
&pMsgDesc->PutTime[4],
&pMsgDesc->PutTime[6]);
printLine(offset,"Event created",valbuf);
It looks like you could use the c function strptime to parse the string into a epoch time stamp and then print that in your local time zone.
Related
I'm uploading a file into Azure Storage Explorer, the blob check every 12 hours for a file, if there is a file an email is sent. When an email is sent I need to get the time and date when the file is uploaded not when the email is sent. I use the List of Files LastModified and the output is like this 2021-09-22T15:15:55Z, I don't need the time in UTC. Is there any way to change convert the time using the List of Files LastModified?
The 'List of Files LastModified' gives the exact thing that you required while in order to change the utc to local/Any time zone that we required, we need to add a function 'convertFromUtc'.
For CST :
formatDateTime(convertTimeZone(utcNow(), 'UTC', 'Central Standard Time'),'HH:mm:ss')
For IST:
formatDateTime(convertTimeZone(utcNow(), 'UTC', 'India Standard Time'),'HH:mm:ss')
else you can perform hardcoded operation such as to SubtractFromTime or AddToTime considering the timezone that we wanted.
Here is the flow of my logic app
REFERENCES :
Reference guide for functions in expressions - Azure Logic Apps | Microsoft Docs
when i describe the kubernates events its showing both creationTimestamp and firstTimestamp, it seems both are same only, What is the exact difference between those timestamps
From source code:
FirstTimestamp: The time at which the event was first recorded. (Time
of server receipt is in TypeMeta.)
LastTimestamp: The time at which the most recent occurrence of this
event was recorded.
EDIT:
Both of these fields mentioned above seem to be set by client library: sourcecode reference
Note: Not that long time ago event api change proposal appeared.
This means thet both FirstTimestamp and LastTimestamp are deprecated in favour of EventTime.
Event creationTimestamp is a field set by api-server during object creation. It's a read only field. source:
// CreationTimestamp is a timestamp representing the server time when this object was
// created. It is not guaranteed to be set in happens-before order across separate operations.
// Clients may not set this value. It is represented in RFC3339 form and is in UTC.
//
// Populated by the system.
// Read-only.
Also have a look at the api server source code for reference to see how its being set.
I am creating YouTube live broadcast using API explorer everything is working fine but Snippet.scheduledStartTime is not working fine.
My time zone is +05:00 and country is Pakistan.
I want to schedule event at 2019-01-18 04:50 PM. I have set the Snippet.scheduledStartTime to 2019-01-18T11:50:00.000Z but on event page it shows Starts January 18, 2019 at 3:50 AM (PST) when I click edit it shows wrong country and time zone like that United States (GMT -08:00) Pacific
I want to use javascript or php client libraries.
Please let me know how I can fix it?
Here is my php code
$broadcastSnippet = new Google_Service_YouTube_LiveBroadcastSnippet();
$broadcastSnippet->setTitle('New Test Broadcast');
$broadcastSnippet->setScheduledStartTime('2019-01-18T11:50:00.000Z');
According to the YouTube Live Streaming API Docs, the format for scheduledStartTime must be in ISO 8601 format:
datetime
The date and time that the broadcast is scheduled to start.
The value is specified in ISO 8601 (YYYY-MM-DDThh:mm:ss.sZ) format.
I would suggest that you check the time zone designator you have set.
Create date with timezone
I am not a PHP dev but the smartest thing to do IMO would be to create a date in the correct timezone and then out put it in the correct format. After about five minutes of googleing i found this.
$tz = 'Europe/London';
$timestamp = time();
$dt = new DateTime("now", new DateTimeZone($tz)); //first argument "must" be a string
$dt->setTimestamp($timestamp); //adjust the object to correct timestamp
echo $dt->format('c');
I want to fetch record from the sys_user table which is updated at or after certain time stamp.
for that I have created rest request as
https:/service-now.com/api/now/v1//table/sys_user?sysparm_query=sys_updated_on>=javascript:gs.dateGenerate('2017-10-30','01:25:00')
I had converted current time which is in IST format into GMT and pass it to dateGenerate() function.
Problem statement -
I don't want to convert the IST to GMT, is there any way by which i can identify ServiceNow instance time zone at runtime and convert given time into that time stamp and get the users.
If i can pass this date and time in UTC format.
Ahoy!
This is a great question, and something that's quite difficult in ServiceNow (dealing with time-zones).
As such, I've written a tool to manage this for you. It's totally free!
The tool is called TimeZoneUtil, and can be found here:
https://snprotips.com/blog/2017/9/12/handling-timezones-in-servicenow-timezoneutil
You simply need to initialize a GlideDateTime object, set its' time-zone to IST, use setDisplayValue() to set its' time based on IST current time, then use .getValue() to get that same time in system time.
This is because getDisplayValue()/setDisplayValue() work based on time-zone, whereas setValue()/getValue() always return the corresponding system time.
EDIT: In order to make this a little more clear, I'll provide some example usage below.
var tz = new TimeZoneUtils(); //initialize with current time
gs.print(tz.getOffsetHours()); //prints out "-7" in my instance, as the system time is in Pacific.
tz.setTimeZone('Asia/Kolkata'); //sets the time-zone to IST/UTC+5.5
gs.print(tz.getOffsetHours()); //prints "5.5".
gs.print(tz.getGDT().getDisplayValue()); //Prints the current time in IST (2017-11-01 20:52:31 at the moment).
gs.print(tz.getGDT().getValue()); //Prints the current time in system time (2017-11-01 15:23:12 at present).
gs.print(new TimeZoneUtils().setTimeZone('Asia/Kolkata').getDisplayValue()); //Single line, also prints current time in IST: 2017-11-01 20:52:31
The first 6 lines there, demonstrate basic usage and explain how it works.
The eighth line however, demonstrates usage on a single line, which you can use inside a query string. For example:
sysparm_query=sys_updated_on>=javascript:new TimeZoneUtils().setTimeZone('Asia/Kolkata').getDisplayValue()
Hope this helps!
Tim Woodruff
Author, Learning ServiceNow & Building Powerful Workflows
Owner/Founder, SN Pro Tips
I got in trouble with creation of an all day event appointment using Exchange 2010 Web Services (EWS) .
According to existing requirements to create an All day event appointment object needs to have specified start and end time (i.e. 10/20/2011 12:00:00 AM), and also timezone.
But my application converted to use EWS instead of WebDAV sets start and end time converted to GMT (Greenwich) time which then sent to Exchange server.
Such technique worked perfectly with WebDAV.
But with EWS I get weird result: appointment spans on 3 (three) days, and is NOT All day event appointment !!!
My mailbox timezone set to Pacific Standard Time (using OWA interface), and Exchange server Date and Time also set to Pacific Standard time.
Appointment start and end times are set to “2011-10-20T07:00:00.000Z” and “2011-10-21T07:00:00.000Z” respectively.
In terms of local time these times are “10/20/2011 12:00:00 AM” and “10/21/2011 12:00:00 AM” respectively (considering Daylight Saving time).
If IsAllDayEvent property of appointment object set to False – appointment created correctly – not as All day, starts at 10/20/2011 12AM and ends at 10/21/2011 12AM, and occupies only one day – October /20/2011 in Outlook Calendar.
But If isAllDayEvent property of appointment object set to True (everything rest remains the same) – appointment starts at Oct/19/2011 9:00:00PM, ends at Oct/21/2011 9:00:00PM, and is NOT All day.
It might be that I’m doing something wrong, but based on described above following question raised for me:
does EWS support Greenwich Time for All day events?
If yes – what might be my mistakes?
I appreciate any suggestion.
Sincerely
Andrew
Ran into a similar problem where my all day event was being created from 4pm the previous day to 4pm the specified date of the all day event (I'm currently in pacific standard time -8 so appears to be a UTC bug on the exchange server side).
When calling Appointment.save, use the optional second parameter, SendInvitationsMode.SendToNone, e.g.:
a.save(new FolderId(WellKnownFolderName.Calendar),
SendInvitationsMode.SendToNone);
If you prefer XML see Envelope/Body/CreateItem/#SendMeetingInvitations:
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages"
xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types">
<soap:Header>
<t:RequestServerVersion Version="Exchange2007"></t:RequestServerVersion>
</soap:Header>
<soap:Body>
<m:CreateItem SendMeetingInvitations="SendToNone">
<m:SavedItemFolderId>
<t:DistinguishedFolderId Id="calendar"></t:DistinguishedFolderId>
</m:SavedItemFolderId>
<m:Items>
<t:CalendarItem>
<t:Subject>From Java EWS</t:Subject>
<t:Body BodyType="HTML">the body</t:Body>
<t:Start>2014-01-03T00:00:00Z</t:Start>
<t:End>2014-01-04T00:00:00Z</t:End>
<t:IsAllDayEvent>true</t:IsAllDayEvent>
</t:CalendarItem>
</m:Items>
</m:CreateItem>
</soap:Body>
</soap:Envelope>
In addition to Pete's answer:Note that there is a difference between what Exchange has stored and what Outlook tells you. I'm writing 'pure' SOAP XML calls to an Exchange 2010 Server calendar and viewing the results through Outlook 2003. The creation calls explicitly specify UTC times and have no other time zone information. The server has UTC settings.
If I now create an allday event like this:
<mes:CreateItem SendMeetingInvitations="SendToNone">
<mes:Items>
<typ:CalendarItem>
<typ:Subject>Alldayevent</typ:Subject>
<typ:Start>2013-01-08T01:00:00.000Z</typ:Start>
<typ:End>2013-01-08T02:00:00.000Z</typ:End>
<typ:IsAllDayEvent>true</typ:IsAllDayEvent>
... Exchange correctly stores this as (GetItem output):
<t:Start>2013-01-08T00:00:00Z</t:Start>
<t:End>2013-01-09T00:00:00Z</t:End>
<t:IsAllDayEvent>true</t:IsAllDayEvent>
If Outlook is also configured for UTC this shows as an all day event for 8. January (as expected).
However, if I set Outlook to UTC+1 (Amsterdam time), the event is displayed extending over two days (and note he checkbox being blank):
Checking 'All day' in that situation results in (GetItem output):
<t:Start>2013-01-07T23:00:00Z</t:Start>
<t:End>2013-01-09T23:00:00Z</t:End>
<t:IsAllDayEvent>true</t:IsAllDayEvent>
I'm doing a DAV to EWS conversion myself. Something that might be of interest I ran across from Best Practices for Using Exchange Web Services for Calendaring Tasks (Ex 2007, but I assume applies to Exchange 2010 and 2013)
When Exchange Web Services receives a request to create a new CalendarItem for which the start and End properties are identified by non-UTC-offset strings, the server must convert the Start and End properties to Coordinated Universal Time (UTC) before the CalendarItem can be stored. The following are the rules for the conversion to UTC:
If the request contains an explicit time zone definition via a MeetingTimeZone property, the server will apply the correct offset with regard to Standard and Daylight rules as defined by the time zone.
If no explicit time zone is defined, the current time zone of the computer that is running Exchange 2007 (specifically, the Client Access server that is processing the request) will be used.
Note:
In Exchange 2007 SP1, all unspecified time zones are set to UTC instead of the time zone of the Client Access server.
Experimenting a little bit, I found that if you do not specify a timezone, EWS will indeed apply the time as UTC. If IsAllDayEvent is true start times and end are ignored besides their date component. So an all day event turns into 12:00am-12:00am UTC or 5:00pm-5:00pm on my calendar (I'm -7 UTC also). The Best Practices article recommends using the MeetingTimeZone element, but I received an error that it was depreciated, use StartTimeZone and EndTimeZone instead. Indeed adding <StartTimeZone Id="Pacific Standard Time"> seems to work.
As far as your 3 day issue goes I was able to reproduce similar results. Here is what I suspect is happening. If you tell Exchange the start time is 7am and end time is 8am, and flag it all day, it will automatically set the start and end times to yyy-mm-ddT00:00:00 and yyy-mm-dd+1T00:00:00. So if I send an appointment for 2011-11-04T07:00:00 to 2011-11-05T07:00:00 w/o the timezone element, it thinks I'm trying to span two days. The start time 2011-11-04T07:00:00 becomes 2011-11-04T00:00:00 to 2011-11-05T00:00:00. The end time 2011-11-05T07:00:00 becomes becomes 2011-11-05T00:00:00 to 2011-11-06T00:00:00. This gets thrown on the calendar as UTC. When viewed it in Outlook or in webapp it displays it in PST as Nov 3rd 5pm - Nov 6th 5pm and looks like its spanning 3 days (but only actually only 48 hours).
You need to specified MeetingTimeZone(for ES2007) or StartTimeZone(for ES2010+). I had the same problem, and it helped me.