javax.net.ssl记录时间戳格式具有奇怪的小时价值

发布于 2025-02-13 05:53:41 字数 1275 浏览 0 评论 0原文

我正在使用python来解析通过jetty.net.ssl在运行我无法访问的JVM的外部平台上生产的一些日志文件。

由于我不了解的原因（也无法在任何地方找到记录），日志时间戳每天的第一个小时表示为24而不是00 EG

javax.net.ssl|DEBUG|15|Mux|2022-07-01 24:00:11.298 UTC|SSLSocketOutputRecord.java:334|WRITE: TLSv1.3 application_data, length = 31

， 2022-07- 01 00：00：00：11.298，而不是2022-07- 02 00：00：00：11.298

这种格式破坏了事物像Python的dateTime.dateTime（）和dateutils.parser.parse（）。我可以在此围绕此编码，使用正则划分将时间戳字符串的各个元素剥离，并在必要时更改时间，但是，我沿着我的线条


        timere = re.compile(r"^(\d{4})-(\d{2})-(\d{2})\s+(\d{2}).(\d{2}).(\d{2})\.(\d{3}).*$")
        if not (match:=timere.match(tstr)):
            raise ValueError(f"Time string {tstr} is not valid")
        yy = int(match.groups()[0])
        mm = int(match.groups()[1])
        dd = int(match.groups()[2])
        hr = int(match.groups()[3]) % 24
        mi = int(match.groups()[4])
        se = int(match.groups()[5])
        us = int(match.groups()[6]) * 1000
        d = datetime.datetime(yy, mm, dd, hr, mi, se, us, tzinfo=datetime.timezone.utc)

很感兴趣 为什么 时间戳在那儿。格式，我不知道有些微妙吗？我有点假设开发人员出于我尚不了解的原因故意使用“ 24”作为有效的时光。

原文

I'm using Python to parse some logfiles produced via jetty.net.ssl on an external platform running a JVM to which I have no access.

For reasons I don't understand (and nor can I find documented anywhere) the log timestamps have the first hour of each day expressed as 24 rather than 00 e.g.

javax.net.ssl|DEBUG|15|Mux|2022-07-01 24:00:11.298 UTC|SSLSocketOutputRecord.java:334|WRITE: TLSv1.3 application_data, length = 31

which corresponds to 2022-07-01 00:00:11.298 rather than 2022-07-02 00:00:11.298

This format breaks things like Python's datetime.datetime() and dateutils.parser.parse(). I can code around this, stripping out the various elements of the timestamp string using a regex and altering the hour where necessary, along the lines of


        timere = re.compile(r"^(\d{4})-(\d{2})-(\d{2})\s+(\d{2}).(\d{2}).(\d{2})\.(\d{3}).*quot;)
        if not (match:=timere.match(tstr)):
            raise ValueError(f"Time string {tstr} is not valid")
        yy = int(match.groups()[0])
        mm = int(match.groups()[1])
        dd = int(match.groups()[2])
        hr = int(match.groups()[3]) % 24
        mi = int(match.groups()[4])
        se = int(match.groups()[5])
        us = int(match.groups()[6]) * 1000
        d = datetime.datetime(yy, mm, dd, hr, mi, se, us, tzinfo=datetime.timezone.utc)

I am, however, intrigued as to why the timestamps are in that format and is there some subtlety of which I am unaware? I'm kind of assuming that the developers used "24" as a valid hour deliberately for reasons I don't yet understand.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

作死小能手 2025-02-20 05:53:41

openjdk sun.security.ssl.sslogger 使用以下语法来输出时间戳。

private static final String PATTERN = "yyyy-MM-dd kk:mm:ss.SSS z";
private static final DateTimeFormatter dateTimeFormat = 
    DateTimeFormatter.ofPattern(PATTERN, Locale.ENGLISH)
                     .withZone(ZoneId.systemDefault());

这意味着小时由kk部分表示，根据 java.time.format.datetimeformatter 是“ clock-hour-of-day（1-24）”

不确定Python是否具有可以使用的日期/时间模式相同的日期/时间模式。

The OpenJDK sun.security.ssl.SSLLogger uses the following syntax to output the timestamp.

private static final String PATTERN = "yyyy-MM-dd kk:mm:ss.SSS z";
private static final DateTimeFormatter dateTimeFormat = 
    DateTimeFormatter.ofPattern(PATTERN, Locale.ENGLISH)
                     .withZone(ZoneId.systemDefault());

This means the hour is represented by kk portion, which according to java.time.format.DateTimeFormatter is "clock-hour-of-day (1-24)"

Not sure if python has the same date/time pattern it can use.

回复收藏 0 原文

~没有更多了~