Displaying the timezone properly in XSLT - date

Was using the below tag for displaying the timezone which was working fine until now when the daylight saving has happened and as our server is in UK displaying the time as 01/04/2015 03:43:00 PM + 0100, we would also like to have the timezone displayed, please advice.
Tag Used Previously:
date:format-date(date:date-time(), 'dd/MM/yyyy hh:mm:ss a Z')
Regards
Arvind

If by "properly" you mean you want it displayed as "BST" (for British Summer Time) then there isn't actually enough information in the date/time value to do this - a time-zone offset of +1 occurs in many different timezones near the Greenwich meridian.
You're using the EXSLT library for formatting dates and times. This is based on Java's SimpleDateFormat class, so you could try your luck with the timezone designator z instead of Z.
Alternatively, if you've got access to XSLT 2.0, you can use the format-dateTime() function. This suffers from the same problem (the dateTime value only stores an offset, which doesn't actually tell you the name of the timezone). But you can give the processor a clue by setting the 5th argument of format-dateTime() to "Europe/London", in which case it might be able to work it out.

Related

Rundeck time format

In the "Activity for jobs' page in Rundeck the execution time has a relative time field (example: "Today at 10:15 AM" or "Last Sunday at 4:51 AM") after the timestamp.
It is easy to change the date format of the timestamp by adding jobslist...format[.ko] in the i18n/messages.properties file.
It seems impossible however to change the format of the relative time message. It seems to be hard-coded in en_US with AM/PM which doesn't look too good in in non-English-speaking countries. The format is always the same regardless of the ?lang=xx parameter or the default language in the browser. Interestingly, other objects (like hovering over the field with the mouse and the duration get translated).
Has anyone successfully changed this?
Example. See the duration field
I have been trying this with the docker images (4.8.0, 4.9.0 and SNAPSHOT)
I've looked at the source code and apparently this lies somewhere in the moment.js code.
In some parts, the date formats are hard coded as you say, please add your use case on this thread.

Google Calendar api ignores timezone

Im using the CalendarApi in flutter and in order to get events I use the list method like that:
calendarApi.events.list(
cls.calendarId,
timeZone: <specific timezone>
timeMin: DateTime.now().today().toUtc(),
timeMax: DateTime.now().tomorrow().toUtc(),
),
No matter what timezone I tried it always return the event start and end date in UTC format.
I tried using the timezones in multiple formats:
America/Los_Angeles
UTC - 08:00
GMT format
Pacific Standard Time
None of the following worked.
In addition in the in google calendar's settings the timezone is set correctly.
From the documentation:
Must be an RFC3339 timestamp with mandatory time zone offset, for example, 2011-06-03T10:00:00-07:00, 2011-06-03T10:00:00Z. Milliseconds may be provided but are ignored. If timeMax is set, timeMin must be smaller than timeMax.
Make sure the strings you are sending follow one of these pattens:
YYYY-MM-DDTHH:MM:SS±HH:MM
or
YYYY-MM-DDTHH:MM:SSZ
So for example, the time that this answer was posted would be:
2021-07-27T16:08:02+02:00
or:
2021-07-27T14:08:02Z
Where the Z signifies 'Zulu', or UTC.

ZonedDateTime value incorrect after loading via Spring Boot JPA, PostgreSQL

I have a ZonedDateTime with a specific instant in time, with the Zone set to America/Los_Angeles.
If I display this using the pattern "d-MMM-uuuu HH:mm VV" it shows as I expect (e.g. ... 8:00 am America/Los_Angeles).
However, if I change the pattern very minimally by removing the "VV", then it does not show the time in west coast time, it shows it in my local time (east coast), or 11:00 am - so it essentially ignores the zone set on the ZonedDateTime and instead uses something else (I assume the system local zone).
I would prefer to not display the time zone id in some cases, to save space (in a table for instance), but still want it to be displayed in the local time.
Is there a way to do that?
Update:
I note that using the pattern "d-MMM-uuuu HH:mm O", surprisingly, gives what I consider a wrong answer:
2-Jun-2020 11:09 GMT-7
here is the correct time, which shows using VV:
2-Jun-2020 08:09 America/Los_Angeles
The 11am value with "GMT-7" looks like it is clearly a bug - granted I am still using Java 8.
Update:
I think the problem may be in the data layer, though I am still trying to figure that out... (I am using Spring Boot JPA and PostgreSQL).
If I just purely use Java, as such:
ZoneId pdt = ZoneId.of("America/Los_Angeles");
ZonedDateTime now = ZonedDateTime.now().withZoneSameInstant(pdt);
logger.debug("now with VV: "+now.format(DateTimeFormatter.ofPattern("d-MMM-uuuu HH:mm VV")));
logger.debug("now with O: "+now.format(DateTimeFormatter.ofPattern("d-MMM-uuuu HH:mm O")));
logger.debug("now with nothing: "+now.format(DateTimeFormatter.ofPattern("d-MMM-uuuu HH:mm")));
logger.debug("now with VV+withZ: "+now.format(DateTimeFormatter.ofPattern("d-MMM-uuuu HH:mm VV").withZone(pdt)));
logger.debug("now with O+withZ: "+now.format(DateTimeFormatter.ofPattern("d-MMM-uuuu HH:mm O").withZone(pdt)));
logger.debug("now with nothing+withZ: "+now.format(DateTimeFormatter.ofPattern("d-MMM-uuuu HH:mm").withZone(pdt)));
logger.debug("using static formatter: "+now.format(TIMESTAMP_FORMATTER_SHORT));
logger.debug("using static formatter w/zone: "+now.format(TIMESTAMP_FORMATTER_SHORT.withZone(pdt)));
then in every case it shows the expected correct time in LA.
So, in debugging to see the differences, I see this anomaly:
In plain java if I look at the value of now (in code above), it looks correct - the LocalDateTime shows the current time in LA, and the offset is 7 hrs.
If I look at the ZonedDateTime value that is set after the JPA load, however, it looks unusual:
the value stored in the DB has the hour at 15 (as expected, UTC time)
the value in the LocalDateTime within the ZonedDateTime is off - it is showing the hour as 11, which is the local system time, not the time in LA
however the ZonedDateTime offset is still -7
What is really odd about this is that somehow DateTimeFormatter corrects the problem, but only when I use VV in the format.
I have determined the problem (not with JPA or PostgreSQL unsurprisingly).
Rather this is a bug that had been introduced a long time ago, but never exposed until I switched to trying to show a shorter display of the timestamp.
The code actually causing the problem was post processing a native query, incorrectly converting a java.sql.Timestamp into a ZonedDateTime. Here is the problem code:
java.sql.Timestamp timestamp = (Timestamp) objects[0];
String tzId = (String) objects[1];
ZonedDateTime dt = ZonedDateTime.of(timestamp.toLocalDateTime(), ZoneId.of(tzId));
I was incorrectly assuming that the ZonedDateTime.of would use the provided ZoneId to revise the time, but I believe that is not how it works. Instead, the toLocalDateTime() was creating a LocalDateTime based on the system default, which therefore did not agree with the ZoneId value passed in, which was the value stored in the DB and not the same as the system default.
Here is how I corrected the code:
java.sql.Timestamp timestamp = (Timestamp) objects[0];
String tzId = (String) objects[1];
ZonedDateTime dt = ZonedDateTime.of(timestamp.toLocalDateTime(), ZoneId.systemDefault())
.withZoneSameInstant(ZoneId.of(tzId));

Powershell simplest method to get current time expressed as UTC

I have reviewed the post Creating a DateTime object with a specific UTC DateTime in PowerShell, but it does not seem to directly answer the question I am asking:
What is the most direct method in PowerShell (3.0) to return a sortable string representing "now" as UTC?
I expected the correct answer to be:
Get-Date -Format (Get-Culture).DateTimeFormat.UniversalSortableDateTimePattern
OR
get-date -format u
but this is not the case.
Example: At 1300 hrs (1pm) on September 1st, 2016 in the Pacific Time Zone during DST, I get the response:
2016-09-01 13:00:00Z (the local time with a "Z" appended)
when I was expecting:
2016-09-01 20:00:00Z (correct UTC/GMT time)
So basically, my code is just getting a string representing the "local" time and appending a "Z".
Now, I know I can manipulate to get to that point, but I'm looking for the minimal (simplest, cleanest) way to get here.
Bonus Points (as if they existed): How do I get that same, sortable result, but displaying with "UTC" and/or "GMT" as the suffix. Same minimal requirement.
Probably something like this:
[DateTime]::UtcNow.ToString('u')
Which is equivalent to:
[DateTime]::UtcNow.ToString((Get-Culture).DateTimeFormat.UniversalSortableDateTimePattern)
For the bonus, I think the most straightforward way is just to replace Z with UTC:
[DateTime]::UtcNow.ToString('u').Replace('Z','UTC')
I'm assuming you'll always want UTC since that what it seems like from your question. There doesn't appear to be a format string to get just the 3 letter time zone.
I tried this, and it also gives the result I want:
"[DateTime]::UtcNow.ToString('yyyyMMdd_HHmmss_UTC')"
It is showing time in the format 20180108_152407_UTC
so you can play with the date/time formatting as you wish basically

Google Calendar API doesn't accept DateTime with positive UTC offset?

I'm developing an iOS app that accesses a Google Calendar to display dates of upcoming livestreams.
Google claims that for any argument that takes a DateTime, it must be formatted as ISO 8601, which I understand should look like this: 2015-05-17T18:49:11-07:00 (I live in Southern California, which is normally UTC-08:00 but right now is UTC-07:00 because of Daylight Savings Time) Anyway, in my own testing, my app is generating URLs like the following:
https://www.googleapis.com/calendar/v3/calendars/CALENDAR_IDENTIFIER/events?orderBy=startTime&q=Live&singleEvents=true&timeMin=2015-05-17T18:49:11-07:00&timeMax=2015-06-16T18:49:11-07:00&key=API_KEY
and these are working perfectly, they return the expected calendar data.
However I just recently added a tester who lives in New Zealand, who is in UTC+12:00. His app is generating URLs such as this:
https://www.googleapis.com/calendar/v3/calendars/CALENDAR_IDENTIFIER/events?orderBy=startTime&q=Live&singleEvents=true&timeMin=2015-05-17T13:49:11+12:00&timeMax=2015-06-16T13:49:11+12:00&key=API_KEY
however for him they are NOT working, they return a "400 Bad Request" error from Google.
I did some experimentation, and in my findings, any negative UTC offsets that I try work correctly (e.g. Hawaii, who is UTC-11:00, Anchorage which is UTC-09:00) however none of the positive GMT offsets work (New Zealand # UTC+12:00, Japan # UTC+09:00)
What am I doing wrong?
Edit: I've worked around the issue for now by converting all of my times into UTC and specifying them as, e.g., 2015-05-17T18:49:11Z, then adding timeZone=America/Los_Angeles (or Asia/Tokyo or wherever the user is) to the API call. Google seems to accept this. I'd still like to know why, even though they claim that ISO 8601 format strings are accepted, they in actuality aren't (this is especially odd/puzzling/frustrating considering that Google's reply, i.e. the actual calendar data that my app receives, in fact, actually contains ISO 8601 date strings with positive offsets, such as 2015-06-15T09:00:00+09:00.)
Yep, this seems to be a bug. I'm in Spain (UTC+01:00) and I was going crazy with this, given that the response data is as you say formatted with the positive offset.
I'm using it for the timeMin paramter in the http request to get only future events. Ended up putting the current datetime adding the last "Z" as string. Apparently works fine, but I'm in the same timezone the calendar has defined. When that is not the case I guess you have a problem there if you want it with hour precession.
The timeZone parameter apparently is only for the response data.
It works if + is encoded as %2B.