I'm working on integrating with an API that (unfortunately) does not always append the timezone offset to their date. I know this isn't optimal but I can't change their behavior.
Example:
2022-06-08T16:07:13.96
Using the java generator and the java8 date library produces a runtime error while parsing the date:
java.time.format.DateTimeParseException: Text '2022-06-08T16:07:13.96' could not be parsed at index 22
at java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2052)
at java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1954)
at java.base/java.time.OffsetDateTime.parse(OffsetDateTime.java:404)
at com.acme.openapi.JSON$OffsetDateTimeTypeAdapter.read(JSON.java:287)
From my limited understanding, I believe that ISO-8601 dates should be treated as local dates instead of offset dates if the zone offset is omitted. Im unsure if this is something that is supported in the java generator.
I ended up swapping the date library to java8-localdatetime but it gave GSON some problems:
Expected BEGIN_OBJECT but was String
I changed to a jackson based client and that cleared everything up.
I use this nasty wrapper everywhere, where I use a DateTime from the API, to "hack" it in the current timezone.
DateTime utcHack(DateTime dt) {
return DateTime.parse(dt.toLocal().toString() + "Z");
}
I am open for improvements!
Related
I have a simple class that contains a DateTime property. When I set the value of this property using DateTime.Now() the value is correct. However, when I pass this class object as a parameter via SignalR, on the receiving end SignalR has changed the DateTime so that it no longer matches the original DateTime. How can I get SignalR to stop manipulating my DateTime values? This issue seems to have started with a recent update to the latest SignalR nuget packages.
This seems to be a problem when the hub and the client are in two different time zones. It seems Microsoft is trying to help, by adjusting the date/time to the local time zone, but I want the original value, not the value Microsoft "thinks" I want.
When you want two systems to communicate with each other I would recommend using always the DateTime in UTC for various reasons. In your case you have two options here:
1 - Send the date as string string date = DateTime.Now.ToString(CultureInfo.InvariantCulture); so on the client side you just need to parse the datetime like DateTime.Parse(date, CultureInfo.InvariantCulture);.
2 - Send the date in UTC like DateTime.UtcNow; so event if the SignalR tries to change the date, it will have the DateTime.Kind as UTC. In this case or you will get the current date correctly, or you just adjust on the client side to the local time like receivedDate.ToLocalTime();
This one was a real head scratcher as I had the exact same issue. The client was storing the correct time but by the time it hit the Hub... it had changed. I'm really glad you posted this as I wouldn't have imagined this issue being possible. #Kiril1512 posted the correct resolution. In my case I used his second option as I didn't want to change my model... although simply converting to a string would have been simpler. While I did follow his suggestion and convert everything to DateTime.UtcNow()... I am thinking this was unnecessary as I noticed even previously stored dates converted correctly. This makes me think that either this isn't necessary to do, or dates are converted to Utc when they hit the Hub automatically which may be what the issue was to begin with?
Either way I posted this as I discovered that converting this date back to Local time was a little more involved. Here is how I ended up doing the conversion which resolved this issue for me that I gathered from this resource:
DateTime convertedDate = DateTime.SpecifyKind(
DateTime.Parse(msg.CreatedOn.ToString()),
DateTimeKind.Utc);
var kind = convertedDate.Kind;
DateTime dt = convertedDate.ToLocalTime();
We and foolishly assumed a block of momentjs code would work in all browsers. Right now its correctly working in chrome, but all other browsers its not applying the UTC offset. How do I make this code work consistently in other browsers? Right now chrome is working, all others are not.
new moment(new Date(date)).fromNow();
//below shows an example of an exact date.
var now = new moment(new Date("2013-09-30T23:33:36.937")).fromNow();
In chrome you would see something like "now", all other browsers you would see "in 4 hours"
The way to get it to work:
var now = moment.utc("2013-10-01T13:15:30.937").fromNow();
Note that if you turn it into a "Date" and call moment.utc
var now = moment.utc(new Date("2013-10-01T13:15:30.937")).fromNow();
It will not work. It makes sense now that I think of it.
Original Answer
Try this:
var now = moment(date).fromNow();
But rutter is correct that you should specify either a Z or an offset like -07:00. From .net, you should make sure you use either a DateTime with .Kind set to Utc, or use a DateTimeOffset field.
Expanded Answer
You should understand that when you send a string of 2013-10-01T13:15:30.937, you are not sending any context with it. There is no way to know from that string alone whether the time is at UTC, or in your server's time zone, or in the browser's time zone.
If you pass it directly to moment("2013-10-01T13:15:30.937"), it is going to assume the context of the browser's local time zone.
As you discovered, you can tell moment explicitly that this time is in UTC by using the .utc function, such as moment.utc("2013-10-01T13:15:30.937").
While this will work, there are good reasons not to rely on that alone. For example, what if you ever use the same server API for another application, or perhaps for third-parties to consume? Unless you tell them separately that the timestamp is meant to represent UTC, then there is no way to know that.
These strings are in the ISO 8601 / RFC 3339 format. Part of that specification describes how to indicate that a timestamp is in UTC. You simply add a Z at the end. If you supply the Z then any consumer of this timestamp will know that the time should be interpreted as UTC. And sure enough, if you pass that into moment directly, such as moment("2013-10-01T13:15:30.937Z"), it will give the result you expected.
You said in comments that you were generating these values from ASP.Net Web API. Run your application in debug mode and set a breakpoint so you can examine the output of your controller. When you look at the specific DateTime property in question, you will see that it has its own .Kind property. It is probably set to DateTimeKind.Unspecified.
Since you said specifically that your application uses UTC, then these values should have DateTimeKind.Utc instead. Once that is set, then WebAPI will properly emit the Z at the end of the timestamp.
Somewhere in your server-side code, you should do something like this:
dt = DateTime.SpecifyKind(dt, DateTimeKind.Utc);
You should do this as early as possible. For example, in your data access layer when you retrieve the value from the database. If that's not possible, then at least you should do it in your API Controller so the value gets emitted properly.
See also the MSDN reference for DateTimeKind and DateTime.SpecifyKind.
Also - the reason you were getting browser inconsistencies is because you were using the Date object's constructor instead of the parsing functions built in to moment. While moment will accept a Date, there are several known problems and inconsistencies with how browsers support parsing a Date from a string. Some of those inconsistencies are documented here.
Use this:
var lastLoginTime = moment(user.lastLoginTime).fromNow();
How can we parse a Zoned DateTime string using NodaTime? I am currently using LocalDateTimePattern for parsing, but I think that the DateTime value yielded would be in the Server's timezone.
var pattern = LocalDateTimePattern.CreateWithInvariantCulture(dateTimePattern);
var parseResult = pattern.Parse(dateTimeString);
if (!parseResult.Success)
{
// throw an exception or whatever you want to do
}
I came across ZonedDateTime pattern when I was looking at the
Noda Time API. But, I am not able to use it. Am I missing out something?
You don't say which version of Noda Time you're using, but I suspect it's 1.1.0 (that is, the latest released version).
ZonedDateTimePattern is only available in the development version of Noda Time (which will become 1.2.0 when it's released); as mentioned in the roadmap, 1.2.0 will include better text handling, including parsing for ZonedDateTime and OffsetDateTime.
I'm afraid that in 1.1.x there's no way to parse a ZonedDateTime directly (as noted in the limitations section of the 1.1.x user guide), though you could parse an Instant and a timezone name separately, and construct a ZonedDateTime by hand.
I'm having a bit of an issue with the Date (java) / DateTime (.net) type when using the Ambient Data Framework in SDL Tridion 2009.
I'm setting a claim value in java like this:
Date myDate = rs.getDate("DATE_FIELD_IN_DB");
store.put(CLAIM_URI_DATE, myDate);
This is great and life is fantastic :)
In my web application (which is .net) I need to get this value from the claim store, when I try to do so, it fails:
My code is:
if (_store.Contains(new Uri("taf:claim:company:date"))) {
DateTime claimdata = _store.Get<DateTime>("taf:claim:company:date");
Response.Write(claimdata.ToString());
}
And the error message is:
[RuntimeException] Codemesh.JuggerNET.NTypeValue.Throw(Int64 inst)
+373 Codemesh.JuggerNET.JavaClass.ThrowTypedException(Int64 inst) +1365 Codemesh.JuggerNET.JavaMethod.CallInt(JavaProxy jpo) +233 Tridion.ContentDelivery.AmbientData.JuggerNetTypeHelper.FromProxyObject(Object
proxyObject) +738
Tridion.ContentDelivery.AmbientData.ClaimStore.Get(Uri claimUri) +109
I've also tried obtaining as an object, which i then cast to DateTime. I'm obviously making a really basic error here, any help would be greatly appreciated.
I have also read the SDL documentation here : http://sdllivecontent.sdl.com/LiveContent/content/en-US/SDL_Tridion_2011_SPONE/concept_26FDE76C277D43F893175E512EFDF09A which shows the java Data object is converted to the .net DateTime.
Thanks
John
UPDATE
As per the suggestions of Peter, i've check and ensured the correct jar files are in place.
It might be worth mentioning that the date is stored in a SQL database as a 'Date' type, a typical value doesn't include a timestamp, for example '2011-09-03'. Still this all functions great in Java and I can work with the value as a date. Still when getting the value in .Net the typed exception is thrown.
It should convert it automatically. Are you sure you are not using a different Date object than java.util.Date, though? There's quite a few of them out there...
If you really cannot get it to work, you can work around it by storing the date as a string (in ISO 8601 format) and then using DateTime.Parse on the .NET side.
But like I said: it normally works fine so there's probably something else going wrong.
Is your ADF working fine for other things in .NET? Maybe it's missing a setup step for the .NET side of things...
A bit of a long shot, but can you verify that the right JDBC driver is installed as mentioned in this question/answer?
Exception loading CustomMeta from Tridion Broker Service (2009 SP1)
The Date value, does it contain the time? Can you ensure that it does when you get the value from the store?
I just upgraded to the RTM version of the OData Library. I've noticed what appear to be inconsistencies in DateTime handling and would like to know if anyone can explain what I might be missing, or if there are in fact some problems. In addition to the RTM library I'm relying on the 3/30/2012 version of MS-ODATA.
MS-ODATA defines dateTimeUriLiteral in the following format (simplified for example):
YYYY-MM-DDTHH:MM:SS.NS where NS is defined as nanoSeconds=1*7DIGIT
And MS-ODATA defines VJsonDateTime as the dreaded /Date(...)/ format.
However using the Library in verbose JSON serialization we see the dateTimeUriLiteral format, not VJsonDateTime. Furthermore the deserialization accepts only the dateTimeUriLiteral format. This looks like a conflict between the spec and the implementation.
Also, dateTimeUriLiteral makes no allowance for time zone offset (such as would be the case in an ISO 8601 format). However we see that the Library emits a 'Z' terminating character (ISO 8601 for UTC) when the serialized datetime object is designated as DateTimeKind.Utc. This also looks like a conflict between the spec and the implementation.
Also, when we use the Library to deserialize a dateTimeUriLiteral that has the terminating 'Z' - the deserialized object is marked as DateTimeKind.Local. Whether or not there is a spec issue WRT support for the UTC designator, this does not look like it could be correct. Either the 'Z' should cause a deserialization failure or it should result in a time marked as UTC (not local).
Verbose JSON V3 uses the ISO DateTime format (the same one as XML uses). Verbose JSON V2 and V1 use the /Date(...)/ format. So it depends which version of the payload you're writing and reading.
The dateTimeUriLiteral is not the same thing as the Verbose JSON V3 date time format. The one in Verbose JSON V3 uses the Z (it's literaly the same thing as you get from XmlConvert.ToString(datetime, XmlDateTimeSerializationMode.RoundtripKind)).
As for reading the "Z" value. This seems to be a bug. The product team is looking into this in more detail. Possible workaround seems to be to either revert back to V2 format, or use DateTimeOffset values instead (which don't have this problem).