According to https://github.com/FasterXML/jackson-modules-java8/tree/master/datetime Jackson will serialize times as the number of milliseconds since 1970 by default. If SerializationFeature#WRITE_DATES_AS_TIMESTAMPS is set, it will serialize times using ISO-8601.
Obviously 2018-11-03T22:51:00.54-04:00 is a lot more readable than 1541299860.540000000.
Why would anyone favor sending a timestamp over the wire instead of ISO-8601? Does it have any performance advantages perhaps?
Related
I have a string in the following format:
14:41:21 Dec 15, 2015 PST
I want to convert that to my server's local time, but I think I'm creating an extra step that can be avoided:
Dim testdate As Date
DateTime.TryParseExact(dateinput, "HH:mm:ss MMM dd, yyyy PST", CultureInfo.InvariantCulture, DateTimeStyles.None, testdate)
testdate = TimeZoneInfo.ConvertTimeToUtc(testdate, TimeZoneInfo.FindSystemTimeZoneById("Pacific Standard Time"))
testdate = testdate.ToLocalTime()
I've played around with this but always off by a couple hours either way, and the above is what I've found to work but just wanted to know if there was a better way. Also note it could be deployed on multiple servers, so I don't want to specify the timezone to convert it to explicitly, reason for localtime.
A few things:
If you're going to include fixed text in a format string, put it in single-tick quotes so it can't get misinterpreted as a formatting token. ('PST')
In the general case, time zone abbreviations should only be used for display purposes. They should not be parsed as input, as they could be ambiguous. For example, there are 5 different interpretations of CST. It might be US Central Standard Time, but it could also be China Standard Time, or one of the others. See the list on Wikipedia.
If you have a limited number of time zone abbreviations you want to support, then you could extract it from the string and use a dictionary, select/case statements, or conditional logic to map them. Just be certain you know the entire set of abbreviations you want to support and exactly which time zones you want them to map to. Also be sure to account for daylight time abbreviations, such as PDT.
Note that some older standards, such as RFC 2822 §4.3 indeed hardcode a few abbreviations, so you may choose to support those if you are parsing that particular format. (Yours is similar, but not quite a match.)
Your code is mostly ok, but you should probably check the result of TryParseExact. Otherwise you might as well use ParseExact which will throw an exception on failure instead of just returning false.
You could use ConvertTime with TimeZoneInfo.Local as the destination zone if you wanted to do the conversion in a single step. The code would be slightly smaller, though would have no technical differences.
Are you sure you really want to do this? Relying on the system's local time zone should usually should not be done in server-based applications. That's something more appropriate for desktop and mobile. In general, server-side code should not rely on the system time zone to be anything in particular. Avoid "local time" APIs, including DateTime.Now, TimeZoneInfo.Local, ToLocalTime, and ToUniversalTime (when it assumes the input is local time). It is better to supply the applicable time zone in your business logic or application configuration.
I my web REST API service I've decided to return a dateTime data as a string with a timezone which looks like this: "someDate":"2012-01-23T22:52:37.039+02:00" I wonder, how idiomatic is it? If I returned it as Unix time stamp, would it be more sensible?
Personally, I prefer using unix timestamps in situations like this because it is completely timezone agnostic and leaves the timezone interpretation entirely up to the client. Additionally, depending on your client, it's generally less code to parse a unix timestamp into a date than a date string, but that's likely only an ancillary consideration.
Personally I prefer using the “Epoch time”. It’s not very readable, but it’s very well defined and much shorter then other formats.
References:
http://en.wikipedia.org/wiki/System_time
http://en.wikipedia.org/wiki/Unix_time
The format is described in RFC 3339: Date and Time on the Internet: Timestamps
-- a profile of ISO 8601.
It is unambiguous and both human and machine readable.
POSIX timestamp is less readable e.g., 1327351957.039 and there is no indication of a local time.
If parsing datetime strings is a performance bottleneck in your application then you could cache the timestamp value.
I have a WCF web service that is being consumed by ABAP, which expects the 'Z' character at the end for UTC time. The WCF service is serializing it just fine, with the exception of the 'Z'.
That is, it is sending 2014-01-12T19:43:13, where I want it to send 2014-01-12T19:43:13Z.
I have read several posts relating to this, but I am hoping there's a really elegant solution available. Adding another element/member that returns a string is not ideal.
As an alternative, is there a way to specify the format used, so that the client can parse the date time using said format?
You're right, 500 - Internal Server Error, it does, if the DateTime has it's DateTimeKind set to Utc, which it didn't (even though it was in UTC time). I created an extension method, using DateTimeOffset, to return a DateTime with the DateTimeKind set to Utc and all is well.
Scratch that, I opted to use the DateTime.SpecifyKind() method instead, which seems neater.
I've worked with various ORMs and database abstractions designed to make it easy to work with multiple databases, both relational and not. The more comprehensive solutions will usually give you access to some date functions that boil down to actual SQL (or whatever, in the case of non-SQL dbs). On the other hand, many of these abstractions don't provide direct access to SQL functions and you lose the ability to deal with dates directly. Instead, you're expected to use the upper-level language (PHP, Python, whatever) to do your date-wrangling, and finally only insert, select, what-have-you the formatted date.
So my question is this: if the SQL server never gets to do anything with the date itself, am I better off just using an int and putting epoch timestamps in it, or is there additional value to the database server "knowing" it's a date?
If you are using dates, store them as dates.
Not only does this make it easier to translate between the database and application, but when you need to do anything based on the dates (and you will, otherwise why have dates stored at all?).
That is, when you need to sort or query using the dates, you will not need to go trough special effort to re-convert to dates.
Other than what #Oded said, if you never ever use any date related functions, Still there are some issues;
At the moment, you cannot store epoch timestamp in milliseconds into an INT field (overflows).
Timestamp without milliseconds will overflow INT on Tue Jan 19 2038 # 03:14:08 GMT+0000 (GMT) as it will be greater than 2147483647.
BUT, Integer takes 4 bytes and Datetime takes 8 bytes. You are better off 4 bytes if you are within above two limitations.
Pretty simple, I need to disable time zone conversion for specific columns. I will handle any TZ conversion manually, but I need Rails 3 to forego conversion in both writing and reading, and any AREL functions. But, I don't want to disable the conversion for non-specified attributes.
Ok, I know how to disable it for reading:
self.skip_time_zone_conversion_for_attributes = [:test_timestamp]
But this only works for reading. When writing the attribute, it still converts to UTC (yes, I tested this in 3.2.8).
As you note, skip_time_zone_conversion_for_attributes only works for reading, which makes the whole feature pretty useless.
There are two possible solutions:
1.- Accept that with times will be written in UTC, and read accordingly:
def starts_at # override reader method
attributes['starts_at'].in_time_zone(whatever_timezone)
end
cons: overriden method is bypased when using MyModel.pluck(:starts_at).
2.- Store time values as strings, taking care of writing the values in the right format, and reading them in the desired timezone.
def starts_at
DateTime.strptime(attributes['starts_at'], whatever_format).in_time_zone(whatever_timezone)
end
cons: one loses the ability to query the database by using date operators (less than, greater than).