[jira] [Commented] (THRIFT-4363) User-extensible type mappings
[ https://issues.apache.org/jira/browse/THRIFT-4363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16210985#comment-16210985 ] James E. King, III commented on THRIFT-4363: In two projects where time was concerned, I would standardize on passing a unix timestamp no matter what the platform or language. Obviously this is implementation specific, but easy to implement. The ISO 8601 format extended to support fractions of a second seems like it would be acceptable, however I'm not a fan of needing to implement timezone conversions everywhere. I think it would be okay to force this to be a universal time (GMT, UT, whatever you call it wherever you are) based value, and to use a generic format for time duration based on the format used by boost::posix_time::time_duration which converts safely to and from string and is easy to parse. That said, referring to THRIFT-839 this issue was discussed a while back with no plans to implement. However if you are feeling up to it, submitting a pull request with an implementation across most of the languages would be a good start, including cross-test support. If you are feeling up to it, keep this open, otherwise this needs to be resolved as a dupe of THRIFT-839. > User-extensible type mappings > - > > Key: THRIFT-4363 > URL: https://issues.apache.org/jira/browse/THRIFT-4363 > Project: Thrift > Issue Type: Wish > Components: D - Compiler, D - Library >Reporter: Neia Neutuladh >Priority: Minor > > One of the most common types I deal with is a datetime. Another common type > is a time delta. It would be great if these were built in, but that's > unlikely to happen soon. Another option is to put this into the library as a > relatively generic thing: use an annotation to tell the compiler what D type > this thing is, and then have the library figure out how to convert the format > given to the requested type, in a way where the user can override things. > For instance, I have a Timestamp type. It's got an int64 for the epoch second > and an int64 for the nanosecond. I want to turn that into a > std.datetime.DateTime. Optionally, the library can possibly look for a way to > build a DateTime from those components automatically. It won't find one, so > it will produce a fallback that simply produces a reasonable exception. I can > provide a manual converter on application startup. > This lets me have a generated object model that looks more like what I would > have written by hand. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (THRIFT-4363) User-extensible type mappings
[ https://issues.apache.org/jira/browse/THRIFT-4363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16206621#comment-16206621 ] Neia Neutuladh commented on THRIFT-4363: https://issues.apache.org/jira/browse/THRIFT-839 is specific to timestamps (and perhaps needs to be reopened?). This is for the more general case where you have an existing type, where it would be a lot more useful to have that type in your object model than what you can express simply in Thrift IDL. For instance, if I receive a list of items but it would be really handy to treat it as a priority queue, I might want to have that list converted to a red-black tree automatically. Or I have an i32 representing a port number, but all the code I have that deals with ports uses a ushort. > User-extensible type mappings > - > > Key: THRIFT-4363 > URL: https://issues.apache.org/jira/browse/THRIFT-4363 > Project: Thrift > Issue Type: Wish > Components: D - Compiler, D - Library >Reporter: Neia Neutuladh >Priority: Minor > > One of the most common types I deal with is a datetime. Another common type > is a time delta. It would be great if these were built in, but that's > unlikely to happen soon. Another option is to put this into the library as a > relatively generic thing: use an annotation to tell the compiler what D type > this thing is, and then have the library figure out how to convert the format > given to the requested type, in a way where the user can override things. > For instance, I have a Timestamp type. It's got an int64 for the epoch second > and an int64 for the nanosecond. I want to turn that into a > std.datetime.DateTime. Optionally, the library can possibly look for a way to > build a DateTime from those components automatically. It won't find one, so > it will produce a fallback that simply produces a reasonable exception. I can > provide a manual converter on application startup. > This lets me have a generated object model that looks more like what I would > have written by hand. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (THRIFT-4363) User-extensible type mappings
[ https://issues.apache.org/jira/browse/THRIFT-4363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16206610#comment-16206610 ] Jens Geyer commented on THRIFT-4363: We had that discussion a whikle ago on the mailing lists. Main problem here is that there are so many (actually used) date/time formats with different offsets and precisions across OSes and languages. It's hard to find a common denominator, but (personal opinion) it could be worth a try to find one other than strings like in [http://www.w3.org/TR/NOTE-datetime|this W3C note] or [https://en.wikipedia.org/wiki/ISO_8601|ISO 8601]. FWIW, we usually use double for out datetime values here, but I also used C# ticks occasionally. > User-extensible type mappings > - > > Key: THRIFT-4363 > URL: https://issues.apache.org/jira/browse/THRIFT-4363 > Project: Thrift > Issue Type: Wish > Components: D - Compiler, D - Library >Reporter: Neia Neutuladh >Priority: Minor > > One of the most common types I deal with is a datetime. Another common type > is a time delta. It would be great if these were built in, but that's > unlikely to happen soon. Another option is to put this into the library as a > relatively generic thing: use an annotation to tell the compiler what D type > this thing is, and then have the library figure out how to convert the format > given to the requested type, in a way where the user can override things. > For instance, I have a Timestamp type. It's got an int64 for the epoch second > and an int64 for the nanosecond. I want to turn that into a > std.datetime.DateTime. Optionally, the library can possibly look for a way to > build a DateTime from those components automatically. It won't find one, so > it will produce a fallback that simply produces a reasonable exception. I can > provide a manual converter on application startup. > This lets me have a generated object model that looks more like what I would > have written by hand. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
