W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > February 2011

[Bug 12043] For better compatibility with .SRT, could the FULL STOP be replaced with a COMMA? So instead of 00:00:00.000 it would be 00:00:00,000

From: <bugzilla@jessica.w3.org>
Date: Sat, 12 Feb 2011 00:58:28 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1Po3oi-0000Fz-IC@jessica.w3.org>

Silvia Pfeiffer <silviapfeiffer1@gmail.com> changed:

           What    |Removed                     |Added
                 CC|                            |silviapfeiffer1@gmail.com

--- Comment #2 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2011-02-12 00:58:27 UTC ---
(In reply to comment #1)
> I filed this bug while reviewing the WebVTT spec for implementation in a JS
> subtitle engine which already works with .SRT. I was not able to find any
> reasoning for WebVTT's change to a period for the seconds-frac separator.
> SRT: hh:mm:ss,fff
> WebVTT: hh:mm:ss.fff
> I think that re-use of existing SRT tools and implementation of subtitle
> interpreters would be much helped if we could adopt the SRT version for the
> timestamp format. Thanks!

For the sake of allowing denser time specifications in caption files, it would
actually make sense to have a flexibler time specification such as

[[h*:]mm:]ss[.[d[c[m]]]  | s*[.d[c[m]]]

With the denser possibilities of specifying time in this way, it's no longer
compatible with SRT anyway, which prescribes presence of hh and mm and fff.

Incidentally, there are some SRT files that use "." as the seconds-frac
separator already, so existing SRT parsers should already be able to deal with

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Saturday, 12 February 2011 00:58:30 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:05 UTC