The difference between this time and UTC is ( Zone Offset + DST offset ). I think here this feature does not need to describe the LOCAL time nothing but the timestamp and that is in UTC. It makes sense that the plugins use particular FORMAT, forinstance platform format of predefined format by the Maven. It is save to manipulate with the UTC time even if you use it a minute before DST or after. The UTC will be always precisely understood exact clock by Java and Maven too.
On Sun, Oct 6, 2019 at 12:37 PM Michael Osipov <micha...@apache.org> wrote: > I still don't see and issue because the offset is there. If you subtract > or add the offset and you have the Zulu time. > > Can you provide this concrete example? I am quite certain that there was > an error on some side. > > If you case is true, the entire time logic in Java 8 woudn't be able to > perform conversions from Istants to LocalDateTime. > > Am 2019-10-06 um 12:34 schrieb Tibor Digana: > > Michael, it is the problem with summer time. Do you know what i mean?We > had > > this problem in my company therefore we strictly used Z as UTC and if > > somebody sent another timezone we sent back an error from REST. > > You cannot say that you disagree if you do not understand. Pls have it > > logically explained first! > > > > On Sun, Oct 6, 2019 at 12:32 PM Michael Osipov <micha...@apache.org> > wrote: > > > >> Am 2019-10-06 um 12:25 schrieb Tibor Digana: > >>> ISO format was often discussed and this was found as problematic > format > >>> because you cannot always compute it to UTC due to GMT offset. The > offset > >>> is not enough. What is required for EXACT computing to UTC is Time zome > >>> name but this format does not support it. It is exactly the same > problem > >> in > >>> XML. > >> > >> I don't understand that and do not agree. Of course, you can do > >> normalization. Can you please elaborate? > >> > > > >
