<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hello,<div class=""><br class=""></div><div class="">For me it sounds a bit confusing, but maybe it is because of Sunday evening and my head is half in sleeping-mode :-)</div><div class=""><br class=""></div><div class="">I understand that „TimeStamp now“ is my German local timestamp with +1 UTC and „TimeStamp now asUTC“ is +0 UTC. Here it is currently 20:45pm and both are normally the same date, when we look from the standpoint that only day/month/year matters. But of course if I would do the same one minute after German midnight, then the dates differs by one day. So this is surely what you mean with „intentional behavior“ and you are right. The intentional behavior is to represent international dates with timezones, that is what I read now out from your answer. That means also Date >> newDay:month:year: creates more like a UTC date version.</div><div class=""><br class=""></div><div class="">From my standpoint and I like the things „easy“, maybe It would be easier for a programmer and also for the implementation when all chronological objects are generally internally represented in +0 UTC. Not the objects need to be changed/converted, only the display/print string of these objects should be different. As example the standard print string could be time zone dependent, so that I can see all timestamps in my local time zone.</div><div class=""><br class=""></div><div class="">In my project I use only UTC timestamps in objects and disk files and it seems (based on your answer) that I have forget now to send an #asUTC at some place. This would be not needed if all things would be in +0 UTC in any case.</div><div class=""><br class=""></div><div class="">But thanks for your answer, so I will add the #asUTC.</div><div class=""><br class=""></div><div class="">Do you have also an answer for me about Mantis registration/login?</div><div class=""><br class=""></div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">Am 23.01.2022 um 19:56 schrieb Jaromir Matas <<a href="mailto:mail@jaromir.net" class="">mail@jaromir.net</a>>:</div><br class="Apple-interchange-newline"><div class=""><meta charset="UTF-8" class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif; caret-color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">Hi,</div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif; caret-color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">I wonder if it’s really a bug or an intentional behavior… firstDate includes the timezone offset which causes the inequality.</div></div></blockquote></div><br class=""></div></body></html>