Local Time Conversions Across DST Shift - Bug or My Design Flaw?

#23

on mobile … to your last point …I am ok with the parse failing so long as it throws an error that’s user visible in the piston.

#24

Unfortunately it doesn’t currently and it won’t with these changes since the function has a few levels of try/catch to handle alternate formats. We can’t easily distinguish here between expected exceptions (different format than supported by parse) and unexpected exceptions (known format but bad time zone). Java just pumps out an InvalidArgumentException for both.

#25

sigh … thought that might be. at least it’s better than what we have now.

#26

also dont need the ternary … which means we dont need to save the offsets to variables … this works:

if (!(dateOrTimeOrString =~ /(\s[A-Z]{3}((\+|\-)[0-9]{2}\:[0-9]{2}|\s[0-9]{4})?$)/)) {
    def newDate = (new Date()).parse(dateOrTimeOrString + ' ' + formatLocalTime(now(), 'Z'))
    return newDate + (location.timeZone.getOffset(now()) - location.timeZone.getOffset(newDate))
}
else
    return (new Date()).parse(dateOrTimeOrString)
#27

Perfect I think we have a final patch there

#28

+1

need a PR or you got this from here?

#29

I’ll take it if you make it! Otherwise I’ll commit this tomorrow.

#30

sent you PR … thanks for taking of it.

#31

This was just released in v0.3.108.20180906

#32

Basic test looks good! With no changes (never entered Edit mode) I ran a test with the earlier Piston and the results look great. Thanks a ton for your expertise and attention on this!

image
3C195C14-00A4-4659-8000-4928F0CC79F5.png2048×1536 380 KB

#33

…and I assume this is expected behavior with use of he explicit time zone.

Since 12:00 AM 05-Nov-18 at my location is actually EST (vs the specified EDT), WebCoRE is properly knocking off an hour (“fall back”).

image
34F3788D-9B56-49B0-8D8E-0D21AFBF2381.jpeg1377×1033 805 KB

#34

you are welcome.

#35

that is correct.