I don't understand that either. ISO 8601 is neither aware of zones or
DSTs, just abstract offsets which is a good thing. The format Hervé has
chosen is almost correct (comments) left. The way the value has to be
provided can *always* be canonicalized to UTC. I don't see here a big
hurdle to solve a problem. When you provide 2019-10-06T14:30:00+02:00 is
clear and equals to 2019-10-06T12:30:00Z. Same applies for every other
offset.
Please keep in mind that java.util.Date is merely a wrapper around Unix
timestamp. SimpleDateFormat will work.
Am 2019-10-06 um 14:24 schrieb Tibor Digana:
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?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
