dshunter107 commented on PR #2207: URL: https://github.com/apache/streampipes/pull/2207#issuecomment-1826384898
> I have adapted the asset files a bit, hope you are okay with it 🙂 > > I just tested it locally and have some last remarks: > > * You need to register your processor in the class `TransformationExtensionModuleExport`. Otherwise streampipes won't recognize it > * Please align the id in `ProcessingElementBuilder`s `create()` with the name of the resources directory > * The timezone parameter has a lot of values: >  > > I think we need to sort them at least alphabetically. In addition, I would suggest to use a dropdown menu as input dialog (I can help you here, in case you are not sure about how to achieve) Lastly, is my understanding correct that the timezone parameter should be optional? * I believe I registered the processor. Let me know if I did that correctly. * I aligned the Id with the resource directory * I sorted the time zone parameter options. I may need you to point me in the direction of how to do the dropdown menus. Are you saying that there is already code that can easily transform the radio group into a dropdown list? Or are you saying that I would need to create the code to do so? Regarding the Timezone Parameter. I would say the answer to your question is "somewhat"; however, I am not so sure that "optional" is the best word to describe it. It was a little challenging for me to initially wrap my head around java DateTime, so I apologize if the following is not explained well. There are two types of objects when it comes to DateTimes: (1) LocalDateTime, and (2) ZonedDateTime. Like the name suggests, LocalDateTime has both a date and a time but has no information about the time zone that it corresponds to. As a result, it does not map to a specific instance in the real world. It could be any of the 24 hours corresponding to the times in the world or even any of the myriad of ways different countries and locales recognize their time. The LocalDateTime variable leads to the problem discussed in the Github issue associated with this pull request: the LocalDateTime will correspond to the timezone of the current user. To expand on this problem further with an example, if data was being pulled at 3PM in Colorado and was being sent to two apachestreams users in California and New York, the user in California would get a reading of 3pm in California, and the user in New York would get a reading of 3PM in New York. All 3 readings (California, Colorado, and New York) would correspond to a different instance in time. My solution to this was to use the other DateTime variable: ZonedDateTime. In order to place a ZonedDateTime in the event, the time zone must be a part of the ZonedDateTime. Now the California user (once the time zone is entered) would see a reading of 3pm in Colorado, and the New York user would also see a reading of 3pm in Colorado. All 3 locations would correspond to the same instant. With that problem fixed, an interesting wrinkle occurs... The ISODateTime standard could either be a string formatted for LocalDateTime or a string formatted for ZonedDateTime. In the event that the string is already formatted for ZonedDateTime, we would now have a potential for 2 separate time zones applying for the same datetime. One time zone would be from the user and one from the datetime string. In my solution, I made the assumption that the initial location would have the correct time zone in the string, so I ignored the user time zone in preference of the time zone for the datetime string. As a result, to describe my overall solution, I would say it was to make the time zone input mandatory but ignore it if the datetime string already has the time zone. I think making the time zone input optional is definitely doable. The issues that would need to be addressed with that way are (1) if the user does not put in the time zone with a LocalDateTime string and (2) if the user puts in the time zone string with a ZonedDateTimeString. One solution I thought of for issue 1 would be to have a default time zone like "US/Eastern". Let me know if you prefer the route for making the time zone optional. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
